idnits 2.17.1 draft-ietf-rtcweb-alpn-03.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 (April 5, 2016) is 2936 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 300 ** 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 (-20) exists of draft-ietf-rtcweb-security-arch-11 == 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 April 5, 2016 5 Expires: October 7, 2016 7 Application Layer Protocol Negotiation for Web Real-Time Communications 8 (WebRTC) 9 draft-ietf-rtcweb-alpn-03 11 Abstract 13 Application Layer Protocol Negotiation (ALPN) labels are defined for 14 use in identifying Web Real-Time Communications (WebRTC) usages of 15 Datagram Transport Layer Security (DTLS). Labels are provided for 16 identifying a session that uses a combination of WebRTC compatible 17 media and data, and for identifying a session requiring 18 confidentiality protection from web applications. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 7, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 56 2. ALPN Labels for WebRTC . . . . . . . . . . . . . . . . . . . 2 57 3. Media Confidentiality . . . . . . . . . . . . . . . . . . . . 3 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 62 6.2. Informative References . . . . . . . . . . . . . . . . . 6 63 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 Web Real-Time Communications (WebRTC) [I-D.ietf-rtcweb-overview] uses 69 Datagram Transport Layer Security (DTLS) [RFC6347] to secure all 70 peer-to-peer communications. 72 Identifying WebRTC protocol usage with Application Layer Protocol 73 Negotiation (ALPN) [RFC7301] enables an endpoint to positively 74 identify WebRTC uses and distinguish them from other DTLS uses. 76 Different WebRTC uses can be advertised and behavior can be 77 constrained to what is appropriate to a given use. In particular, 78 this allows for the identifications of sessions that require 79 confidentiality protection from the application that manages the 80 signaling for the session. 82 1.1. Conventions and Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in 87 [RFC2119]. 89 2. ALPN Labels for WebRTC 91 The following identifiers are defined for use in ALPN: 93 webrtc: The DTLS session is used to establish keys for Secure Real- 94 time Transport Protocol (SRTP) - known as DTLS-SRTP - as described 95 in [RFC5764]. The DTLS record layer is used for WebRTC data 96 channels [I-D.ietf-rtcweb-data-channel]. 98 c-webrtc: The DTLS session is used for confidential WebRTC 99 communications, where peers agree to maintain the confidentiality 100 of the media, as described in Section 3. However, data provided 101 over data channels do not receive the same level of 102 confidentiality protection. 104 Both identifiers describe the same basic protocol: a DTLS session 105 that is used to provide keys for an SRTP session in combination with 106 WebRTC data channels. Either SRTP or data channels could be absent. 107 The data channels send Stream Control Transmission Protocol (SCTP) 108 [RFC4960] over the DTLS record layer, which can be multiplexed with 109 SRTP on the same UDP flow. WebRTC requires the use of Interactive 110 Communication Establishment (ICE) [RFC5245] to establish the UDP 111 flow, but this is not covered by the identifier. 113 A more thorough definition of what WebRTC communications entail is 114 included in [I-D.ietf-rtcweb-transports]. 116 There is no functional difference between the identifiers except that 117 an endpoint negotiating "c-webrtc" makes a promise to preserve the 118 confidentiality of the media it receives. 120 A peer that is not aware of whether it needs to request 121 confidentiality can use either form. A peer in the client role MUST 122 offer both identifiers if it is not aware of a need for 123 confidentiality. A peer in the server role SHOULD select "webrtc" if 124 it does not need confidentiality protection. 126 3. Media Confidentiality 128 Private communications in WebRTC depend on separating control (i.e., 129 signaling) capabilities and access to media 130 [I-D.ietf-rtcweb-security-arch]. In this way, an application can 131 establish a session that is end-to-end confidential, where the ends 132 in question are user agents (or browsers) and not the signaling 133 application. This allows an application to manage signaling for a 134 session, without having access to the media that is exchanged in the 135 session. 137 Without some form of indication that is securely bound to the 138 session, a WebRTC endpoint is unable to properly distinguish between 139 a session that requires this confidentiality protection and one that 140 does not. The ALPN identifier provides that signal. 142 A browser is required to enforce this confidentiality protection 143 using isolation controls similar to those used in content cross- 144 origin protections (see Section 5.3 [1] of [HTML5]). These 145 protections ensure that media is protected from applications. 147 Applications are not able to read or modify the contents of a 148 protected flow of media. Media that is produced from a session using 149 the "c-webrtc" identifier MUST only be displayed to users. 151 These confidentiality protections do not apply to data that is sent 152 using data channels. Confidential data depends on having both data 153 sources and consumers that are exclusively browser- or user-based. 154 No mechanisms currently exist to take advantage of data 155 confidentiality, though some use cases suggest that this could be 156 useful, for example, confidential peer-to-peer file transfer. 157 Alternative labels might be provided in future to support these use 158 cases. 160 Generally speaking, ensuring confidentiality depends on 161 authenticating the communications peer. This mechanism explicitly 162 does not define a specific authentication method; a WebRTC endpoint 163 that accepts a session with this ALPN identifier MUST respect 164 confidentiality no matter what identity is attributed to a peer. 166 RTP middleboxes and entities that forward media or data cannot 167 promise to maintain confidentiality. Any entity that forwards 168 content, or records content for later access by entities other than 169 the authenticated peer, MUST NOT offer or accept a session with the 170 "c-webrtc" identifier. 172 4. Security Considerations 174 Confidential communications depends on more than just an agreement 175 from browsers. 177 Information is not confidential if it is displayed to those other 178 than to whom it is intended. Peer authentication 179 [I-D.ietf-rtcweb-security-arch] is necessary to ensure that data is 180 only sent to the intended peer. 182 This is not a digital rights management mechanism. Even with an 183 authenticated peer, a user is not prevented from using other 184 mechanisms to record or forward media. This means that (for example) 185 screen recording devices, tape recorders, portable cameras, or a 186 cunning arrangement of mirrors could variously be used to record or 187 redistribute media once delivered. Similarly, if media is visible or 188 audible (or otherwise accessible) to others in the vicinity, there 189 are no technical measures that protect the confidentiality of that 190 media. 192 The only guarantee provided by this mechanism and the browser that 193 implements it is that the media was delivered to the user that was 194 authenticated. Individual users will still need to make a judgment 195 about how their peer intends to respect the confidentiality of any 196 information provided. 198 On a shared computing platform like a browser, other entities with 199 access to that platform (i.e., web applications), might be able to 200 access information that would compromise the confidentiality of 201 communications. Implementations MAY choose to limit concurrent 202 access to input devices during confidential communications sessions. 204 For instance, another application that is able to access a microphone 205 might be able to sample confidential audio that is playing through 206 speakers. This is true even if acoustic echo cancellation, which 207 attempts to prevent this from happening, is used. Similarly, an 208 application with access to a video camera might be able to use 209 reflections to obtain all or part of a confidential video stream. 211 5. IANA Considerations 213 The following two entries are added to the "Application Layer 214 Protocol Negotiation (ALPN) Protocol IDs" registry established by 215 [RFC7301]: 217 webrtc: 219 The "webrtc" label identifies mixed media and data communications 220 using SRTP and data channels: 222 Protocol: WebRTC Media and Data 224 Identification Sequence: 0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc") 226 Specification: This document (RFCXXXX) 228 c-webrtc: 230 The "c-webrtc" label identifies confidential WebRTC 231 communications: 233 Protocol: Confidential WebRTC Media and Data 235 Identification Sequence: 0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63 236 ("c-webrtc") 238 Specification: This document (RFCXXXX) 240 6. References 242 6.1. Normative References 244 [I-D.ietf-rtcweb-data-channel] 245 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 246 Channels", draft-ietf-rtcweb-data-channel-13 (work in 247 progress), January 2015. 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, 251 DOI 10.17487/RFC2119, March 1997, 252 . 254 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 255 Security (DTLS) Extension to Establish Keys for the Secure 256 Real-time Transport Protocol (SRTP)", RFC 5764, 257 DOI 10.17487/RFC5764, May 2010, 258 . 260 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 261 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 262 January 2012, . 264 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 265 "Transport Layer Security (TLS) Application-Layer Protocol 266 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 267 July 2014, . 269 6.2. Informative References 271 [HTML5] Berjon, R., Leithead, T., Doyle Navara, E., O'Connor, E., 272 and S. Pfeiffer, "HTML 5", CR CR-html5-20121217, August 273 2010, . 275 [I-D.ietf-rtcweb-overview] 276 Alvestrand, H., "Overview: Real Time Protocols for 277 Browser-based Applications", draft-ietf-rtcweb-overview-15 278 (work in progress), January 2016. 280 [I-D.ietf-rtcweb-security-arch] 281 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 282 rtcweb-security-arch-11 (work in progress), March 2015. 284 [I-D.ietf-rtcweb-transports] 285 Alvestrand, H., "Transports for WebRTC", draft-ietf- 286 rtcweb-transports-12 (work in progress), March 2016. 288 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 289 RFC 4960, DOI 10.17487/RFC4960, September 2007, 290 . 292 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 293 (ICE): A Protocol for Network Address Translator (NAT) 294 Traversal for Offer/Answer Protocols", RFC 5245, 295 DOI 10.17487/RFC5245, April 2010, 296 . 298 6.3. URIs 300 [1] http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin 302 Author's Address 304 Martin Thomson 305 Mozilla 306 331 E Evelyn Street 307 Mountain View, CA 94041 308 US 310 Email: martin.thomson@gmail.com