draft-ietf-rtcweb-alpn-02.txt   draft-ietf-rtcweb-alpn-03.txt 
RTCWEB M. Thomson RTCWEB M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track January 21, 2016 Intended status: Standards Track April 5, 2016
Expires: July 24, 2016 Expires: October 7, 2016
Application Layer Protocol Negotiation for Web Real-Time Communications Application Layer Protocol Negotiation for Web Real-Time Communications
(WebRTC) (WebRTC)
draft-ietf-rtcweb-alpn-02 draft-ietf-rtcweb-alpn-03
Abstract Abstract
Application Layer Protocol Negotiation (ALPN) labels are defined for Application Layer Protocol Negotiation (ALPN) labels are defined for
use in identifying Web Real-Time Communications (WebRTC) usages of use in identifying Web Real-Time Communications (WebRTC) usages of
Datagram Transport Layer Security (DTLS). Labels are provided for Datagram Transport Layer Security (DTLS). Labels are provided for
identifying a session that uses a combination of WebRTC compatible identifying a session that uses a combination of WebRTC compatible
media and data, and for identifying a session requiring media and data, and for identifying a session requiring
confidentiality protection. confidentiality protection from web applications.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 24, 2016. This Internet-Draft will expire on October 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2
2. ALPN Labels for WebRTC . . . . . . . . . . . . . . . . . . . 2 2. ALPN Labels for WebRTC . . . . . . . . . . . . . . . . . . . 2
3. Media Confidentiality . . . . . . . . . . . . . . . . . . . . 3 3. Media Confidentiality . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 6
6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
Web Real-Time Communications (WebRTC) [I-D.ietf-rtcweb-overview] uses Web Real-Time Communications (WebRTC) [I-D.ietf-rtcweb-overview] uses
Datagram Transport Layer Security (DTLS) [RFC6347] to secure all Datagram Transport Layer Security (DTLS) [RFC6347] to secure all
peer-to-peer communications. peer-to-peer communications.
Identifying WebRTC protocol usage with Application Layer Protocol Identifying WebRTC protocol usage with Application Layer Protocol
Negotiation (ALPN) [RFC7301] enables an endpoint to positively Negotiation (ALPN) [RFC7301] enables an endpoint to positively
identify WebRTC uses and distinguish them from other DTLS uses. identify WebRTC uses and distinguish them from other DTLS uses.
Different WebRTC uses can be advertised and behavior can be Different WebRTC uses can be advertised and behavior can be
constrained to what is appropriate to a given use. In particular, constrained to what is appropriate to a given use. In particular,
this allows for the identifications of sessions that require this allows for the identifications of sessions that require
confidentiality protection. confidentiality protection from the application that manages the
signaling for the session.
1.1. Conventions and Terminology 1.1. Conventions and Terminology
At times, this document falls back on shorthands for establishing The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
interoperability requirements on implementations: the capitalized "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
words "MUST", "SHOULD" and "MAY". These terms are defined in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. ALPN Labels for WebRTC 2. ALPN Labels for WebRTC
The following identifiers are defined for use in ALPN: The following identifiers are defined for use in ALPN:
webrtc: The DTLS session is used to establish keys for a Secure webrtc: The DTLS session is used to establish keys for Secure Real-
Real-time Transport Protocol (SRTP) - known as DTLS-SRTP - as time Transport Protocol (SRTP) - known as DTLS-SRTP - as described
described in [RFC5764]. The DTLS record layer is used for WebRTC in [RFC5764]. The DTLS record layer is used for WebRTC data
data channels [I-D.ietf-rtcweb-data-channel]. channels [I-D.ietf-rtcweb-data-channel].
c-webrtc: The DTLS session is used for confidential WebRTC c-webrtc: The DTLS session is used for confidential WebRTC
communications, where peers agree to maintain the confidentiality communications, where peers agree to maintain the confidentiality
of the media, as described in Section 3. However, data provided of the media, as described in Section 3. However, data provided
over data channels does not receive confidentiality protection. over data channels do not receive the same level of
confidentiality protection.
Both identifiers describe the same basic protocol: a DTLS session Both identifiers describe the same basic protocol: a DTLS session
that is used to provide keys for an SRTP session in combination with that is used to provide keys for an SRTP session in combination with
WebRTC data channels. Either SRTP or data channels could be absent. WebRTC data channels. Either SRTP or data channels could be absent.
The data channels send Stream Control Transmission Protocol (SCTP) The data channels send Stream Control Transmission Protocol (SCTP)
[RFC4960] over the DTLS record layer, which can be multiplexed with [RFC4960] over the DTLS record layer, which can be multiplexed with
SRTP on the same UDP flow. WebRTC requires the use of Interactive SRTP on the same UDP flow. WebRTC requires the use of Interactive
Communication Establishment (ICE) [RFC5245] to establish the UDP Communication Establishment (ICE) [RFC5245] to establish the UDP
flow, but this is not covered by the identifier. flow, but this is not covered by the identifier.
skipping to change at page 3, line 30 skipping to change at page 3, line 31
included in [I-D.ietf-rtcweb-transports]. included in [I-D.ietf-rtcweb-transports].
There is no functional difference between the identifiers except that There is no functional difference between the identifiers except that
an endpoint negotiating "c-webrtc" makes a promise to preserve the an endpoint negotiating "c-webrtc" makes a promise to preserve the
confidentiality of the media it receives. confidentiality of the media it receives.
A peer that is not aware of whether it needs to request A peer that is not aware of whether it needs to request
confidentiality can use either form. A peer in the client role MUST confidentiality can use either form. A peer in the client role MUST
offer both identifiers if it is not aware of a need for offer both identifiers if it is not aware of a need for
confidentiality. A peer in the server role SHOULD select "webrtc" if confidentiality. A peer in the server role SHOULD select "webrtc" if
it does not prefer either. it does not need confidentiality protection.
3. Media Confidentiality 3. Media Confidentiality
Private communications in WebRTC depend on separating control (i.e., Private communications in WebRTC depend on separating control (i.e.,
signaling) capabilities and access to media signaling) capabilities and access to media
[I-D.ietf-rtcweb-security-arch]. In this way, an application can [I-D.ietf-rtcweb-security-arch]. In this way, an application can
establish a session that is end-to-end confidential, where the ends establish a session that is end-to-end confidential, where the ends
in question are user agents (or browsers) and not the signaling in question are user agents (or browsers) and not the signaling
application. 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 Without some form of indication that is securely bound to the
session, a WebRTC endpoint is unable to properly distinguish between session, a WebRTC endpoint is unable to properly distinguish between
session that requires confidentiality protection and one that does a session that requires this confidentiality protection and one that
not. The ALPN identifier provides that signal. does not. The ALPN identifier provides that signal.
A browser is required to enforce confidentiality using isolation A browser is required to enforce this confidentiality protection
controls similar to those used in content cross-origin protections using isolation controls similar to those used in content cross-
(see Section 5.3 [1] of [HTML5]). These protections ensure that origin protections (see Section 5.3 [1] of [HTML5]). These
media is protected from applications. Applications are not able to protections ensure that media is protected from applications.
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 Applications are not able to read or modify the contents of a
be displayed to users. protected flow of media. Media that is produced from a session using
the "c-webrtc" identifier MUST only be displayed to users.
These confidentiality protections do not apply to data that is sent These confidentiality protections do not apply to data that is sent
using data channels. Confidential data depends on having both data using data channels. Confidential data depends on having both data
sources and consumers that are exclusively browser- or user-based. sources and consumers that are exclusively browser- or user-based.
No mechanisms currently exist to take advantage of data No mechanisms currently exist to take advantage of data
confidentiality, though some use cases suggest that this could be confidentiality, though some use cases suggest that this could be
useful, for example, confidential peer-to-peer file transfer. useful, for example, confidential peer-to-peer file transfer.
Alternative labels might be provided in future to support these use Alternative labels might be provided in future to support these use
cases. cases.
Generally speaking, ensuring confidentiality depends on Generally speaking, ensuring confidentiality depends on
authenticating the communications peer. This mechanism explicitly authenticating the communications peer. This mechanism explicitly
does not define a specific authentication method; a WebRTC endpoint does not define a specific authentication method; a WebRTC endpoint
that accepts a session with this ALPN identifier MUST respect that accepts a session with this ALPN identifier MUST respect
confidentiality no matter what identity is attributed to a peer. confidentiality no matter what identity is attributed to a peer.
RTP middleboxes and entities that forward media or data cannot RTP middleboxes and entities that forward media or data cannot
promise to maintain confidentiality. Any entity that forwards promise to maintain confidentiality. Any entity that forwards
content, or records content for later access by entities other than content, or records content for later access by entities other than
the authenticated peer, SHOULD NOT offer or accept a session with the the authenticated peer, MUST NOT offer or accept a session with the
"c-webrtc" identifier. "c-webrtc" identifier.
4. Security Considerations 4. Security Considerations
Confidential communications depends on more than just an agreement Confidential communications depends on more than just an agreement
from browsers. from browsers.
Information is not confidential if it is displayed to those other Information is not confidential if it is displayed to those other
than to whom it is intended. Peer authentication than to whom it is intended. Peer authentication
[I-D.ietf-rtcweb-security-arch] is necessary to ensure that data is [I-D.ietf-rtcweb-security-arch] is necessary to ensure that data is
only sent to the intended peer. only sent to the intended peer.
This is not a digital rights management mechanism. Even with an This is not a digital rights management mechanism. Even with an
authenticated peer, a user is not prevented from using other authenticated peer, a user is not prevented from using other
mechanisms to record or forward media. This means that (for example) mechanisms to record or forward media. This means that (for example)
screen recording devices, tape recorders, portable cameras, or a screen recording devices, tape recorders, portable cameras, or a
cunning arrangement of mirrors could variously be used to record or cunning arrangement of mirrors could variously be used to record or
redistribute media once delivered. Similarly, if media is visible or redistribute media once delivered. Similarly, if media is visible or
audible (or otherwise accessible) to others in the vicinity, there audible (or otherwise accessible) to others in the vicinity, there
are no technical measures that protect the confidentiality of that are no technical measures that protect the confidentiality of that
media. In other cases, effects might not be temporally localized: media.
transmitted smells could linger for a period after communications
cease.
The only guarantee provided by this mechanism and the browser that The only guarantee provided by this mechanism and the browser that
implements it is that the media was delivered to the user that was implements it is that the media was delivered to the user that was
authenticated. Individual users will still need to make a judgment authenticated. Individual users will still need to make a judgment
about how their peer intends to respect the confidentiality of any about how their peer intends to respect the confidentiality of any
information provided. information provided.
On a shared computing platform like a browser, other entities with On a shared computing platform like a browser, other entities with
access to that platform (i.e., web applications), might be able to access to that platform (i.e., web applications), might be able to
access information that would compromise the confidentiality of access information that would compromise the confidentiality of
communications. Implementations MAY choose to limit concurrent communications. Implementations MAY choose to limit concurrent
access to input devices during confidential communications session. access to input devices during confidential communications sessions.
For instance, another application that is able to access a microphone For instance, another application that is able to access a microphone
might be able to sample confidential audio that is playing through might be able to sample confidential audio that is playing through
speakers. This is true even if acoustic echo cancellation, which speakers. This is true even if acoustic echo cancellation, which
attempts to prevent this from happening, is used. Similarly, an attempts to prevent this from happening, is used. Similarly, an
application with access to a video camera might be able to use application with access to a video camera might be able to use
reflections to obtain all or part of a confidential video stream. reflections to obtain all or part of a confidential video stream.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 6, line 48 skipping to change at page 6, line 51
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-15 Browser-based Applications", draft-ietf-rtcweb-overview-15
(work in progress), January 2016. (work in progress), January 2016.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-11 (work in progress), March 2015. rtcweb-security-arch-11 (work in progress), March 2015.
[I-D.ietf-rtcweb-transports] [I-D.ietf-rtcweb-transports]
Alvestrand, H., "Transports for WebRTC", draft-ietf- Alvestrand, H., "Transports for WebRTC", draft-ietf-
rtcweb-transports-10 (work in progress), October 2015. rtcweb-transports-12 (work in progress), March 2016.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>. <http://www.rfc-editor.org/info/rfc4960>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010, DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>. <http://www.rfc-editor.org/info/rfc5245>.
 End of changes. 17 change blocks. 
32 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/