idnits 2.17.1 draft-johnston-tram-stun-origin-02.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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (March 31, 2014) is 3672 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-09 == Outdated reference: A later version (-05) exists of draft-ietf-tram-auth-problems-00 == Outdated reference: A later version (-05) exists of draft-ietf-tram-stun-dtls-01 ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 4020 (Obsoleted by RFC 7120) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6122 (Obsoleted by RFC 7622) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Johnston 3 Internet-Draft Avaya 4 Intended status: Informational J. Uberti 5 Expires: October 2, 2014 Google 6 J. Yoakum 7 K. Singh 8 Avaya 9 March 31, 2014 11 An Origin Attribute for the STUN Protocol 12 draft-johnston-tram-stun-origin-02 14 Abstract 16 STUN, or Session Traversal Utilities for NAT, is a protocol used to 17 assist other protocols traverse Network Address Translators or NATs. 18 STUN, and STUN extensions such as TURN, or Traversal Using Relays 19 around NAT, and ICE, Interactive Communications Establishment, have 20 been around for many years but with WebRTC, Web Real-Time 21 Communications, STUN and related extensions are about to see major 22 deployments and implementation due to these protocols being 23 implemented in browsers. This specification defines an ORIGIN 24 attribute for STUN that can be used in similar ways to the HTTP 25 header field of the same name. WebRTC browsers utilizing STUN and 26 TURN would include this attribute which would provide servers with 27 additional information about the STUN and TURN requests they receive. 28 This specification defines the usage of the STUN ORIGIN attribute for 29 web and SIP contexts. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 2, 2014. 48 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 5 66 2. STUN ORIGIN attribute . . . . . . . . . . . . . . . . . . . . . 5 67 2.1. STUN Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.2. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.3. ICE Usage . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 72 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 73 6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 STUN, or Session Traversal Utilities for NAT, is a protocol used to 79 assist other protocols traverse Network Address Translators or NATs. 80 TURN, or Traversal Using Relays around NAT [RFC5766], is a STUN 81 extension [RFC5389] that allows endpoints to acquire a relayed 82 address for media flows. It is most commonly used in conjunction 83 with ICE, Interactive Connectivity Establishment [RFC5245], which is 84 used to establish peer-to-peer flows between endpoints through NATs 85 and firewalls. 87 STUN defines three authentication modes, depending on the STUN usage. 88 For STUN binding requests sent between peers, such as for ICE 89 connectivity checks, a short term authentication method is 90 recommended. Each peer contributes random strings which are 91 exchanged over signaling and used to authenticate the connectivity 92 checks. For TURN, a usage of STUN used to acquire and refresh relay 93 addresses, a long term authentication method is recommended. This 94 authentication is similar to SIP Digest [RFC3261], which involves an 95 authentication challenge for each request. A server, upon receipt of 96 a TURN request, generates an authentication challenge that includes a 97 realm and nonce. The client resends the TURN request supplying a 98 user name and password based on the realm indicated by the server. 99 For a STUN binding request sent to a STUN server, no authentication 100 is recommended, as generating the response is less work for a server 101 than the server utilizing the short term or long term authentication 102 approach. 104 WebRTC, Web Real-Time Communications, adds peer-to-peer real-time, 105 interactive voice and video media capabilities and data channels to 106 browsers [I-D.ietf-rtcweb-overview] without a plugin or download, and 107 allows web developers to access this functionality using JavaScript 108 API calls [WebRTC-API]. WebRTC includes STUN, TURN, and ICE client 109 functionality built into browsers. For a session established between 110 two browsers, if either browser is behind a NAT, a STUN server is 111 necessary. Public STUN servers are currently available and a web 112 application can suggest a particular STUN server be used. In other 113 cases, a TURN server is needed to establish a peer connection. In 114 this case, TURN credentials need to be available to the browser for 115 the long term authentication approach. A TURN server for WebRTC 116 might serve a number of different domains and realms. 118 From the perspective of the web application provider, providing 119 service for a number of different domains and realms, it is useful to 120 know something about the source of the STUN request when processing 121 the request. For a web application provider STUN or TURN server, the 122 server will have no idea which web pages or sites are sending binding 123 requests to the service. In conventional applications, the SOFTWARE 124 attribute would provide some identifying information to the service, 125 but that no longer works when the browser is the application. For a 126 web application provider TURN server, the TURN server does not know 127 which realm to include in an authentication challenge. 129 In the web world, HTTP requests have the concept of origin. The 130 origin of a web page, as defined in [RFC6454], is defined by the 131 URI's scheme, host or IP address, and port portions. The HTTP Origin 132 header field inserted by the web browser carries this information and 133 is useful information for servers that receive HTTP requests 134 generated via JavaScript. For example, Cross Origin Resource 135 Sharing, CORS, allows an HTTP server to serve HTTP requests from 136 multiple origins. 138 This specification proposes extending the origin concept to STUN 139 requests. STUN requests generated by a web browser would include the 140 origin of the HTTP page that is initiating the Peer Connection. 141 Using this extra information, a STUN server could use the origin to 142 determine which STUN binding requests to respond to, reducing the 143 load on a STUN server. Using this information, a TURN server could 144 use the origin to determine which realm to include in the 145 authentication challenge. A TURN server can also use the origin 146 information for logging and analytics, and also as additional 147 information after authentication for providing service. 149 An important use case that the STUN Origin helps solve is the 150 operation of a multi-tenanted TURN server (i.e. a TURN server that 151 serves multiple, perhaps tens of thousands of different domains). 152 The problem associated with this use case is described in Section 4.5 153 of [I-D.ietf-tram-auth-problems]. While it is possible for a TURN 154 server to use the same authentication credentials across many 155 domains, a more likely (and more manageable) scenario is to have 156 separate credentials for each domain, and hence a different realm for 157 each domain. To implement this, a TURN server needs to know which 158 realm to include in authentication challenge to TURN clients. One 159 way to do this would be to create a unique TURN URI for each realm. 160 This would require either a separate IP address or port for each 161 realm, and this unique URI would need to be correctly provisioned by 162 each domain (i.e. included in JavaScript, which then could not be 163 copied between domains). Clearly, this doesn't scale for hundreds or 164 thousands of domains. Origin information solves this problem since 165 TURN requests will contain the domain in the Origin attribute. The 166 TURN server just needs to be configured with a mapping between a 167 domain (conveyed in the Origin) and the realm string (to be used in 168 the authentication challenge). Thus, a single TURN URI could be used 169 across all domains, and the resulting JavaScript code would be 170 portable. There is no need for thousands of IP addresses or ports to 171 be allocated and managed. 173 It has been suggested that this origin insight is not needed if the 174 server_name TLS extension in [RFC6066] is supported. This extension 175 allows a TLS client to provide to the TLS server the name of the 176 server they are contacting. In this case, the STUN or TURN client 177 using TLS transport would provide the domain from the TURN server URI 178 during the TLS client hello, allowing the TURN server to respond with 179 the appropriate server certificate. For the TURN server domain to be 180 used by the TURN server to choose the appropriate realm, this would 181 require a unique TURN URI to be provisioned per realm. This is not 182 scalable for supporting thousands of realms. Also, this URI would 183 need to be provisioned in the JavaScript, making the resulting code 184 non-portable. Finally, [RFC6066] provides no help for UDP or TCP 185 transport, which are the most commonly used transports today for STUN 186 and TURN. 188 Another approach that could be pursued is for the client to be 189 explicitly provisioned with a realm value, to which its username and 190 password are scoped. When using the long-term authentication method 191 to authenticate to a TURN server, the client would include this REALM 192 value in the initial, unauthorized requests, allowing the TURN server 193 to know which REALM to use in its authorization challenge. This 194 approach avoids many of the issues with the RFC 6066 approach, but it 195 still requires the realm value to be explicitly provisioned in 196 Javascript. In addition, it does not work in unauthenticated usages, 197 i.e. STUN binding requests sent to a STUN server. 199 Note that the origin information is most useful as a hint in initial 200 STUN and TURN requests as received by a server. However, origin 201 information still has value for logging and other purposes throughout 202 the session even after authentication. 204 The following sections of this document define the STUN ORIGIN 205 attribute and define its usage. 207 1.1. Requirements Language 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in RFC 2119 [RFC2119]. 213 2. STUN ORIGIN attribute 215 This specification defines how to apply the web origin concept and 216 syntax of [RFC6454] to the STUN protocol. 218 This specification defines a new Attribute to the STUN protocol 219 [RFC5389]. The attribute is called ORIGIN and uses the syntax 220 defined in Section 15 of [RFC5389]. The number used for the this in 221 the type field is 0x802F, chosen in the comprehension optional range. 222 The value of ORIGIN is a variable-length value. It MUST contain a 223 UTF-8 [RFC3629] encoded sequence of characters less than 268 bytes. 224 The value of 268 is chosen to be larger than the maximum 253 225 character domain name plus 8 characters for the URI scheme plus 5 226 characters for the port number. 228 Editor's Note: At the appropriate time, the authors will work with 229 the chairs of TRAM to follow [RFC4020] procedures to ensure that no 230 attribute collisions occur while running code is being developed and 231 tested. 233 For a web browser (HTTP User Agent), the contents of the ORIGIN 234 attribute is the unicode-serialization of an origin defined in 235 Section 6.1 of [RFC6454]. The origin value included is the same as 236 the Origin header field for an HTTP request generated from the web 237 page that is creating the Peer Connection. It does not include any 238 string terminating (\x00) character in the serialization. To ensure 239 backwards compatibility with [RFC3489], the ORIGIN attribute is 240 padded to ensure its length is a multiple of 4 octets. 242 For a SIP User Agent [RFC3261] using STUN and TURN, the ORIGIN 243 attribute is set to be the URI of the registrar server used by the 244 User Agent (i.e. the Request-URI of a REGISTER method). 246 For a Jabber client [RFC6120] using STUN and TURN, the ORIGIN 247 attribute is the Jabber ID (JID) [RFC6122] of the Jabber Server that 248 the client is using. 250 Other contexts can define a usage of the ORIGIN attribute to use an 251 appropriate URI or URL. 253 2.1. STUN Usage 255 For STUN requests sent without authentication to a STUN server (i.e. 256 STUN binding requests sent to a STUN server), the STUN client SHOULD 257 include the ORIGIN attribute. A STUN server can derive additional 258 information for logging and analytics about the request through the 259 ORIGIN attribute, such as the source of the request. For example, an 260 enterprise STUN server might only reply to STUN binding requests from 261 certain domains. 263 2.2. TURN Usage 265 For STUN requests sent using the long-term authentication method, 266 such as TURN [RFC5766] allocate requests, the STUN client SHOULD 267 include the ORIGIN attribute. A TURN server can use the ORIGIN 268 attribute to determine which REALM to include in the authentication 269 challenge. A TURN server can also use the ORIGIN attribute after 270 authentication to provide appropriate service. 272 2.3. ICE Usage 274 For STUN requests sent using the short-term authentication method, 275 such as ICE connectivity checks [RFC5245], the use of the ORIGIN 276 attribute is NOT RECOMMENDED. No valid use cases for the ORIGIN 277 attribute have been identified to date. 279 3. IANA Considerations 281 This specification, if approved, adds a new value to the IANA "STUN 282 Attributes Registry" created by [RFC5389]. The ORIGIN attribute 283 value is 0x802F. 285 4. Security Considerations 287 The security considerations of [RFC6454] apply to this extension. 288 Servers using the information present in the STUN ORIGIN attribute 289 need to realize that this attribute could be set arbitrarily by a 290 non-browser client or modified by an intermediary. The method 291 proposed in this document is not meant to replace existing STUN 292 authentication mechanisms but to provide additional information to 293 the server for logging and analytics and how to handle the request 294 after authentication. 296 Just as browsers do not allow a web application to set the Origin 297 header field via JavaScript, browsers should not allow a web 298 application through JavaScript to set the STUN ORIGIN attribute. 300 If the STUN MESSAGE-INTEGRITY attribute is present, the contents of 301 the ORIGIN attribute are integrity protected. The strength of this 302 protection is a function of the secret used to generate the MESSAGE- 303 INTEGRITY value. 305 The STUN ORIGIN attribute does have privacy implications. The 306 recipient of the STUN request learns the web origin of the user. In 307 addition, an on-path attacker could determine this information by 308 inspecting STUN messages between the STUN client and STUN server, 309 depending on the transport used. This information is often available 310 in other messages sent by the browser, such as DNS or HTTP requests. 311 However, in cases where secure HTTP is used, including the ORIGIN 312 attribute over an unencrypted transport could leak this information. 313 STUN has a defined TLS transport; however, TLS transport is generally 314 unsuitable for the real-time media flows that follow STUN requests 315 and must use the same transport. The DTLS transport for STUN 316 [I-D.ietf-tram-stun-dtls] provides a very good privacy solution to 317 this problem. In cases where privacy is paramount, the ORIGIN 318 attribute SHOULD NOT be included or only included if DTLS or TLS 319 transport is used. 321 5. Acknowledgements 323 Thanks to John Selbie, Tirumaleswar Reddy, and Simon Perreault for 324 their feedbak and reviews. 326 6. Normative References 328 [I-D.ietf-rtcweb-overview] 329 Alvestrand, H., "Overview: Real Time Protocols for Brower- 330 based Applications", draft-ietf-rtcweb-overview-09 (work 331 in progress), February 2014. 333 [I-D.ietf-tram-auth-problems] 334 Reddy, T., R, R., Perumal, M., and A. Yegin, "Problems 335 with STUN Authentication for TURN", 336 draft-ietf-tram-auth-problems-00 (work in progress), 337 March 2014. 339 [I-D.ietf-tram-stun-dtls] 340 Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 341 Layer Security (DTLS) as Transport for Session Traversal 342 Utilities for NAT (STUN)", draft-ietf-tram-stun-dtls-01 343 (work in progress), March 2014. 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 349 A., Peterson, J., Sparks, R., Handley, M., and E. 350 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 351 June 2002. 353 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 354 "STUN - Simple Traversal of User Datagram Protocol (UDP) 355 Through Network Address Translators (NATs)", RFC 3489, 356 March 2003. 358 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 359 10646", STD 63, RFC 3629, November 2003. 361 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 362 Standards Track Code Points", RFC 4020, February 2005. 364 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 365 (ICE): A Protocol for Network Address Translator (NAT) 366 Traversal for Offer/Answer Protocols", RFC 5245, 367 April 2010. 369 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 370 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 371 October 2008. 373 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 374 Relays around NAT (TURN): Relay Extensions to Session 375 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 377 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 378 Extension Definitions", RFC 6066, January 2011. 380 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 381 Protocol (XMPP): Core", RFC 6120, March 2011. 383 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 384 Protocol (XMPP): Address Format", RFC 6122, March 2011. 386 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 387 December 2011. 389 [WebRTC-API] 390 Bergkvist, A., Burnett, D., Jennings, C., and A. 391 Narayanan, "WebRTC 1.0: Real-time Communication Between 392 Browsers", W3C Working Draft http://www.w3.org/TR/webrtc/, 393 2013, . 395 Authors' Addresses 397 Alan Johnston 398 Avaya 399 St. Louis, MO 400 USA 402 Phone: 403 Email: alan.b.johnston@gmail.com 404 Justin Uberti 405 Google 406 Kirkland, WA 407 USA 409 Phone: 410 Email: justin@uberti.name 412 John Yoakum 413 Avaya 414 Cary, NC 415 USA 417 Phone: 418 Email: yoakum@avaya.com 420 Kundan Singh 421 Avaya 422 San Francisco, CA 423 USA 425 Phone: 426 Email: kundan10@gmail.com