idnits 2.17.1 draft-ietf-rtcweb-alpn-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 5, 2016) is 2912 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 309 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-11 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-15 == Outdated reference: A later version (-17) exists of draft-ietf-rtcweb-transports-12 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track May 5, 2016 5 Expires: November 6, 2016 7 Application Layer Protocol Negotiation for Web Real-Time Communications 8 (WebRTC) 9 draft-ietf-rtcweb-alpn-04 11 Abstract 13 This document specifies two Application Layer Protocol Negotiation 14 (ALPN) labels for use with Web Real-Time Communications (WebRTC). 15 The "webrtc" label identifies regular WebRTC communications: a DTLS 16 session that is used establish keys for Secure Real-time Transport 17 Protocol (SRTP) or to establish data channels using SCTP over DTLS. 18 The "c-webrtc" label describes the same protocol, but the peers also 19 agree to maintain the confidentiality of the media by not sharing it 20 with other applications. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 6, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 58 2. ALPN Labels for WebRTC . . . . . . . . . . . . . . . . . . . 2 59 3. Media Confidentiality . . . . . . . . . . . . . . . . . . . . 3 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 6.2. Informative References . . . . . . . . . . . . . . . . . 6 65 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 Web Real-Time Communications (WebRTC) [I-D.ietf-rtcweb-overview] uses 71 Datagram Transport Layer Security (DTLS) [RFC6347] to secure all 72 peer-to-peer communications. 74 Identifying WebRTC protocol usage with Application Layer Protocol 75 Negotiation (ALPN) [RFC7301] enables an endpoint to positively 76 identify WebRTC uses and distinguish them from other DTLS uses. 78 Different WebRTC uses can be advertised and behavior can be 79 constrained to what is appropriate to a given use. In particular, 80 this allows for the identification of sessions that require 81 confidentiality protection from the application that manages the 82 signaling for the session. 84 1.1. Conventions and Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as described in 89 [RFC2119]. 91 2. ALPN Labels for WebRTC 93 The following identifiers are defined for use in ALPN: 95 webrtc: The DTLS session is used to establish keys for Secure Real- 96 time Transport Protocol (SRTP) - known as DTLS-SRTP - as described 97 in [RFC5764]. The DTLS record layer is used for WebRTC data 98 channels [I-D.ietf-rtcweb-data-channel]. 100 c-webrtc: The DTLS session is used for confidential WebRTC 101 communications, where peers agree to maintain the confidentiality 102 of the media, as described in Section 3. The confidentiality 103 protections ensure that media is protected from other 104 applications, but the confidentiality protections do not extend to 105 messages on data channels. 107 Both identifiers describe the same basic protocol: a DTLS session 108 that is used to provide keys for an SRTP session in combination with 109 WebRTC data channels. Either SRTP or data channels could be absent. 110 The data channels send Stream Control Transmission Protocol (SCTP) 111 [RFC4960] over the DTLS record layer, which can be multiplexed with 112 SRTP on the same UDP flow. WebRTC requires the use of Interactive 113 Communication Establishment (ICE) [RFC5245] to establish the UDP 114 flow, but this is not covered by the identifier. 116 A more thorough definition of what WebRTC communications entail is 117 included in [I-D.ietf-rtcweb-transports]. 119 There is no functional difference between the identifiers except that 120 an endpoint negotiating "c-webrtc" makes a promise to preserve the 121 confidentiality of the media it receives. 123 A peer that is not aware of whether it needs to request 124 confidentiality can use either identifier. A peer in the client role 125 MUST offer both identifiers if it is not aware of a need for 126 confidentiality. A peer in the server role SHOULD select "webrtc" if 127 it does not prefer either. 129 An endpoint that requires media confidentiality might negotiate a 130 session with a peer that does not support this specification. 131 Endpoint MUST abort a session if it requires confidentiality but does 132 not successfully negotiate "c-webrtc". A peer that is willing to 133 accept "webrtc" SHOULD assume that a peer that does not support this 134 specification has negotiated "webrtc" unless signaling provides other 135 information; however, a peer MUST NOT assume that "c-webrtc" has been 136 negotiated unless explicitly negotiated. 138 3. Media Confidentiality 140 Private communications in WebRTC depend on separating control (i.e., 141 signaling) capabilities and access to media 142 [I-D.ietf-rtcweb-security-arch]. In this way, an application can 143 establish a session that is end-to-end confidential, where the ends 144 in question are user agents (or browsers) and not the signaling 145 application. This allows an application to manage signaling for a 146 session, without having access to the media that is exchanged in the 147 session. 149 Without some form of indication that is securely bound to the 150 session, a WebRTC endpoint is unable to properly distinguish between 151 a session that requires this confidentiality protection and one that 152 does not. The ALPN identifier provides that signal. 154 A browser is required to enforce this confidentiality protection 155 using isolation controls similar to those used in content cross- 156 origin protections (see Section 5.3 [1] of [HTML5]). These 157 protections ensure that media is protected from applications. 158 Applications are not able to read or modify the contents of a 159 protected flow of media. Media that is produced from a session using 160 the "c-webrtc" identifier MUST only be displayed to users. 162 The promise to apply confidentiality protections do not apply to data 163 that is sent using data channels. Confidential data depends on 164 having both data sources and consumers that are exclusively browser- 165 or user-based. No mechanisms currently exist to take advantage of 166 data confidentiality, though some use cases suggest that this could 167 be useful, for example, confidential peer-to-peer file transfer. 168 Alternative labels might be provided in future to support these use 169 cases. 171 This mechanism explicitly does not define a specific authentication 172 method; a WebRTC endpoint that accepts a session with this ALPN 173 identifier MUST respect confidentiality no matter what identity is 174 attributed to a peer. 176 RTP middleboxes and entities that forward media or data cannot 177 promise to maintain confidentiality. Any entity that forwards 178 content, or records content for later access by entities other than 179 the authenticated peer, MUST NOT offer or accept a session with the 180 "c-webrtc" identifier. 182 4. Security Considerations 184 Confidential communications depends on more than just an agreement 185 from browsers. 187 Information is not confidential if it is displayed to those other 188 than to whom it is intended. Peer authentication 189 [I-D.ietf-rtcweb-security-arch] is necessary to ensure that data is 190 only sent to the intended peer. 192 This is not a digital rights management mechanism. A user is not 193 prevented from using other mechanisms to record or forward media. 194 This means that (for example) screen recording devices, tape 195 recorders, portable cameras, or a cunning arrangement of mirrors 196 could variously be used to record or redistribute media once 197 delivered. Similarly, if media is visible or audible (or otherwise 198 accessible) to others in the vicinity, there are no technical 199 measures that protect the confidentiality of that media. 201 The only guarantee provided by this mechanism and the browser that 202 implements it is that the media was delivered to the user that was 203 authenticated. Individual users will still need to make a judgment 204 about how their peer intends to respect the confidentiality of any 205 information provided. 207 On a shared computing platform like a browser, other entities with 208 access to that platform (i.e., web applications), might be able to 209 access information that would compromise the confidentiality of 210 communications. Implementations MAY choose to limit concurrent 211 access to input devices during confidential communications sessions. 213 For instance, another application that is able to access a microphone 214 might be able to sample confidential audio that is playing through 215 speakers. This is true even if acoustic echo cancellation, which 216 attempts to prevent this from happening, is used. Similarly, an 217 application with access to a video camera might be able to use 218 reflections to obtain all or part of a confidential video stream. 220 5. IANA Considerations 222 The following two entries are added to the "Application Layer 223 Protocol Negotiation (ALPN) Protocol IDs" registry established by 224 [RFC7301]: 226 webrtc: 228 The "webrtc" label identifies mixed media and data communications 229 using SRTP and data channels: 231 Protocol: WebRTC Media and Data 233 Identification Sequence: 0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc") 235 Specification: This document (RFCXXXX) 237 c-webrtc: 239 The "c-webrtc" label identifies WebRTC communications with a 240 promise to protect media confidentiality: 242 Protocol: Confidential WebRTC Media and Data 244 Identification Sequence: 0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63 245 ("c-webrtc") 247 Specification: This document (RFCXXXX) 249 6. References 251 6.1. Normative References 253 [I-D.ietf-rtcweb-data-channel] 254 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 255 Channels", draft-ietf-rtcweb-data-channel-13 (work in 256 progress), January 2015. 258 [I-D.ietf-rtcweb-security-arch] 259 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 260 rtcweb-security-arch-11 (work in progress), March 2015. 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, 264 DOI 10.17487/RFC2119, March 1997, 265 . 267 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 268 Security (DTLS) Extension to Establish Keys for the Secure 269 Real-time Transport Protocol (SRTP)", RFC 5764, 270 DOI 10.17487/RFC5764, May 2010, 271 . 273 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 274 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 275 January 2012, . 277 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 278 "Transport Layer Security (TLS) Application-Layer Protocol 279 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 280 July 2014, . 282 6.2. Informative References 284 [HTML5] Berjon, R., Leithead, T., Doyle Navara, E., O'Connor, E., 285 and S. Pfeiffer, "HTML 5", CR CR-html5-20121217, August 286 2010, . 288 [I-D.ietf-rtcweb-overview] 289 Alvestrand, H., "Overview: Real Time Protocols for 290 Browser-based Applications", draft-ietf-rtcweb-overview-15 291 (work in progress), January 2016. 293 [I-D.ietf-rtcweb-transports] 294 Alvestrand, H., "Transports for WebRTC", draft-ietf- 295 rtcweb-transports-12 (work in progress), March 2016. 297 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 298 RFC 4960, DOI 10.17487/RFC4960, September 2007, 299 . 301 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 302 (ICE): A Protocol for Network Address Translator (NAT) 303 Traversal for Offer/Answer Protocols", RFC 5245, 304 DOI 10.17487/RFC5245, April 2010, 305 . 307 6.3. URIs 309 [1] http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin 311 Author's Address 313 Martin Thomson 314 Mozilla 315 331 E Evelyn Street 316 Mountain View, CA 94041 317 US 319 Email: martin.thomson@gmail.com