draft-ietf-rtcweb-alpn-01.txt   draft-ietf-rtcweb-alpn-02.txt 
RTCWEB M. Thomson RTCWEB M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track February 28, 2015 Intended status: Standards Track January 21, 2016
Expires: September 1, 2015 Expires: July 24, 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-01 draft-ietf-rtcweb-alpn-02
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.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 September 1, 2015. This Internet-Draft will expire on July 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
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.
skipping to change at page 3, line 7 skipping to change at page 3, line 7
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 a Secure
Real-time Transport Protocol (SRTP) - known as DTLS-SRTP - as Real-time Transport Protocol (SRTP) - known as DTLS-SRTP - as
described in [RFC5764]. The DTLS record layer is used for WebRTC described in [RFC5764]. The DTLS record layer is used for WebRTC
data channels [I-D.ietf-rtcweb-data-channel]. data 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 communications, as described in Section 3. of the media, as described in Section 3. However, data provided
over data channels does not receive 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 MAY 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.
A more thorough definition of what WebRTC communications entail is A more thorough definition of what WebRTC communications entail is
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 data 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 prefer either.
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.
A browser is required to enforce this control using isolation
controls similar to those used in cross-origin protections. These
protections ensure that media is protected from applications.
Applications 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.
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 session that requires confidentiality protection and one that does
not. not. The ALPN identifier provides that signal.
A browser is required to enforce confidentiality using isolation A browser is required to enforce confidentiality using isolation
controls similar to those used in content cross-origin protections controls similar to those used in content cross-origin protections
(see Section 5.3 [1] of [HTML5]). These protections ensure that (see Section 5.3 [1] of [HTML5]). These protections ensure that
media is protected from applications. Applications are not able to media is protected from applications. Applications are not able to
read or modify the contents of a protected flow of media. Media that 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 is produced from a session using the "c-webrtc" identifier MUST only
be displayed to users. 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
skipping to change at page 5, line 31 skipping to change at page 5, line 22
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
The following two entries are added to the "Application Layer The following two entries are added to the "Application Layer
Protocol Negotiation (ALPN) Protocol IDs" registry established by Protocol Negotiation (ALPN) Protocol IDs" registry established by
[RFC7301]. [RFC7301]:
The "webrtc" identifies mixed media and data communications using webrtc:
SRTP and data channels:
Protocol: WebRTC Media and Data The "webrtc" label identifies mixed media and data communications
using SRTP and data channels:
Identification Sequence: 0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc") Protocol: WebRTC Media and Data
Specification: This document (RFCXXXX) Identification Sequence: 0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc")
The "c-webrtc" identifies confidential WebRTC communications: Specification: This document (RFCXXXX)
Protocol: Confidential WebRTC Media and Data c-webrtc:
Identification Sequence: 0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63 The "c-webrtc" label identifies confidential WebRTC
("c-webrtc") communications:
Specification: This document (RFCXXXX) Protocol: Confidential WebRTC Media and Data
6. References Identification Sequence: 0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63
("c-webrtc")
Specification: This document (RFCXXXX)
6. References
6.1. Normative References 6.1. Normative References
[I-D.ietf-rtcweb-data-channel] [I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-11 (work in Channels", draft-ietf-rtcweb-data-channel-13 (work in
progress), July 2014. progress), January 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, July 2014. Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <http://www.rfc-editor.org/info/rfc7301>.
6.2. Informative References 6.2. Informative References
[HTML5] Berjon, R., Leithead, T., Doyle Navara, E., O'Connor, E., [HTML5] Berjon, R., Leithead, T., Doyle Navara, E., O'Connor, E.,
and S. Pfeiffer, "HTML 5", CR CR-html5-20121217, August and S. Pfeiffer, "HTML 5", CR CR-html5-20121217, August
2010, <http://www.w3.org/TR/2012/CR-html5-20121217/>. 2010, <http://www.w3.org/TR/2012/CR-html5-20121217/>.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-11 Browser-based Applications", draft-ietf-rtcweb-overview-15
(work in progress), August 2014. (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-10 (work in progress), July 2014. 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-06 (work in progress), August 2014. rtcweb-transports-10 (work in progress), October 2015.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
4960, September 2007. RFC 4960, DOI 10.17487/RFC4960, September 2007,
<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, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
6.3. URIs 6.3. URIs
[1] http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin [1] http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin
Author's Address Author's Address
Martin Thomson Martin Thomson
Mozilla Mozilla
331 E Evelyn Street 331 E Evelyn Street
 End of changes. 31 change blocks. 
43 lines changed or deleted 49 lines changed or added

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