idnits 2.17.1 draft-ietf-rtcweb-alpn-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 23, 2014) is 3558 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 295 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-09 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-09 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-09 == Outdated reference: A later version (-17) exists of draft-ietf-rtcweb-transports-04 -- 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 (~~), 6 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 July 23, 2014 5 Expires: January 24, 2015 7 Application Layer Protocol Negotiation for Web Real-Time Communications 8 (WebRTC) 9 draft-ietf-rtcweb-alpn-00 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. 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 January 24, 2015. 37 Copyright Notice 39 Copyright (c) 2014 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. 81 1.1. Conventions and Terminology 83 At times, this document falls back on shorthands for establishing 84 interoperability requirements on implementations: the capitalized 85 words "MUST", "SHOULD" and "MAY". These terms are defined in 86 [RFC2119]. 88 2. ALPN Labels for WebRTC 90 The following identifiers are defined for use in ALPN: 92 webrtc: The DTLS session is used to establish keys for a Secure 93 Real-time Transport Protocol (SRTP) - known as DTLS-SRTP - as 94 described in [RFC5764]. The DTLS record layer is used for WebRTC 95 data channels [I-D.ietf-rtcweb-data-channel]. 97 c-webrtc: The DTLS session is used for confidential WebRTC 98 communications, where peers agree to maintain the confidentiality 99 of the communications, as described in Section 3. 101 A more thorough definition of what WebRTC communications entail is 102 included in [I-D.ietf-rtcweb-transports]. 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 MAY 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 with 117 respect to the promise that an endpoint makes with respect to the 118 confidentiality of session content. An endpoint negotiating 119 "c-webrtc" makes a promise to preserve the confidentiality of the 120 data it receives. 122 Only one of these labels can be used for any given session. A peer 123 acting in the client role MUST NOT offer both identifiers. A peer in 124 the server role that receives a ClientHello containing both labels 125 MUST reject the session, though it MAY accept the confidential option 126 and protect content accordingly. 128 3. Media Confidentiality 130 Private communications in WebRTC depend on separating control (i.e., 131 signaling) capabilities and access to media 132 [I-D.ietf-rtcweb-security-arch]. In this way, an application can 133 establish a session that is end-to-end confidential, where the ends 134 in question are user agents (or browsers) and not the signaling 135 application. 137 A browser is required to enforce this control using isolation 138 controls similar to those used in cross-origin protections. These 139 protections ensure that media is protected from applications. 140 Applications are not able to read or modify the contents of a 141 protected flow of media. Media that is produced from a session using 142 the "c-webrtc" identifier MUST only be displayed to users. 144 Without some form of indication that is securely bound to the 145 session, a WebRTC endpoint is unable to properly distinguish between 146 session that requires confidentiality protection and one that does 147 not. 149 A browser is required to enforce confidentiality using isolation 150 controls similar to those used in content cross-origin protections 151 (see Section 5.3 [1] of [HTML5]). These protections ensure that 152 media is protected from applications. Applications are not able to 153 read or modify the contents of a protected flow of media. Media that 154 is produced from a session using the "c-webrtc" identifier MUST only 155 be displayed to users. 157 Confidentiality protections of this sort are not expected to be 158 possible for data that is sent using data channels. Thus, it is 159 expected that data channels will not be employed for sessions that 160 negotiate confidentiality. In the browser context, confidential data 161 depends on having both data sources and consumers that are 162 exclusively browser- or user-based. No mechanisms currently exist to 163 take advantage of data confidentiality, though some use cases suggest 164 that this could be useful, for example, confidential peer-to-peer 165 file transfer. 167 Generally speaking, ensuring confidentiality depends on 168 authenticating the communications peer. This mechanism explicitly 169 does not define a specific authentication method; a WebRTC endpoint 170 that accepts a session with this ALPN identifier MUST respect 171 confidentiality no matter what identity is attributed to a peer. 173 RTP middleboxes and entities that forward media or data cannot 174 promise to maintain confidentiality. Any entity that forwards 175 content, or records content for later access by entities other than 176 the authenticated peer, MUST NOT offer or accept a session with the 177 "c-webrtc" identifier. 179 4. Security Considerations 181 Confidential communications depends on more than just an agreement 182 from browsers. 184 Information is not confidential if it is displayed to those other 185 than to whom it is intended. Peer authentication 186 [I-D.ietf-rtcweb-security-arch] is necessary to ensure that data is 187 only sent to the intended peer. 189 This is not a digital rights management mechanism. Even with an 190 authenticated peer, a user is not prevented from using other 191 mechanisms to record or forward media. This means that (for example) 192 screen recording devices, tape recorders, portable cameras, or a 193 cunning arrangement of mirrors could variously be used to record or 194 redistribute media once delivered. Similarly, if media is visible or 195 audible (or otherwise accessible) to others in the vicinity, there 196 are no technical measures that protect the confidentiality of that 197 media. In other cases, effects might not be temporally localized: 198 transmitted smells could linger for a period after communications 199 cease. 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 session. 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 The "webrtc" identifies mixed media and data communications using 227 SRTP and data channels: 229 Protocol: WebRTC Media and Data 231 Identification Sequence: 0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc") 233 Specification: This document (RFCXXXX) 235 The "c-webrtc" identifies confidential WebRTC communications: 237 Protocol: Confidential WebRTC Media and Data 238 Identification Sequence: 0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63 239 ("c-webrtc") 241 Specification: This document (RFCXXXX) 243 6. References 245 6.1. Normative References 247 [I-D.ietf-rtcweb-data-channel] 248 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 249 Channels", draft-ietf-rtcweb-data-channel-09 (work in 250 progress), May 2014. 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, March 1997. 255 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 256 Security (DTLS) Extension to Establish Keys for the Secure 257 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 259 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 260 Security Version 1.2", RFC 6347, January 2012. 262 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 263 "Transport Layer Security (TLS) Application-Layer Protocol 264 Negotiation Extension", RFC 7301, July 2014. 266 6.2. Informative References 268 [HTML5] Berjon, R., Leithead, T., Doyle Navara, E., O'Connor, E., 269 and S. Pfeiffer, "HTML 5", CR CR-html5-20121217, August 270 2010, . 272 [I-D.ietf-rtcweb-overview] 273 Alvestrand, H., "Overview: Real Time Protocols for Brower- 274 based Applications", draft-ietf-rtcweb-overview-09 (work 275 in progress), February 2014. 277 [I-D.ietf-rtcweb-security-arch] 278 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 279 rtcweb-security-arch-09 (work in progress), February 2014. 281 [I-D.ietf-rtcweb-transports] 282 Alvestrand, H., "Transports for RTCWEB", draft-ietf- 283 rtcweb-transports-04 (work in progress), April 2014. 285 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 286 4960, September 2007. 288 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 289 (ICE): A Protocol for Network Address Translator (NAT) 290 Traversal for Offer/Answer Protocols", RFC 5245, April 291 2010. 293 6.3. URIs 295 [1] http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin 297 Author's Address 299 Martin Thomson 300 Mozilla 301 331 E Evelyn Street 302 Mountain View, CA 94041 303 US 305 Email: martin.thomson@gmail.com