idnits 2.17.00 (12 Aug 2021) /tmp/idnits2833/draft-nandakumar-rtcweb-turn-uri-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 date (October 25, 2011) is 3854 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) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB S. Nandakumar 3 Internet-Draft G. Salgueiro 4 Intended status: Standards Track P. Jones 5 Expires: April 27, 2012 Cisco Systems 6 October 25, 2011 8 URI Scheme for Traversal Using Relays around NAT (TURN) Protocol 9 draft-nandakumar-rtcweb-turn-uri-00 11 Abstract 13 This document is the specification of the syntax and semantics of the 14 Uniform Resource Identifier (URI) scheme for the Traversal Using 15 Relays around NAT (TURN) protocol. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 27, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. URI Scheme Definition . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 4 56 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 5.1. The 'turn' URI Scheme Registration . . . . . . . . . . . . 5 59 5.2. The 'turns' URI Scheme Registration . . . . . . . . . . . . 6 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 This document specifies the syntax and semantics of the Uniform 70 Resource Identifier (URI) scheme for the Traversal Using Relays 71 around NAT (TURN) protocol. 73 The TURN protocol is a specification allowing hosts behind NAT to 74 control the operation of a relay server. The relay server allows 75 hosts to exchange packets with its peers. The peers themselves may 76 also be behind NATs. RFC 5766 [RFC5766] defines the specifics of the 77 TURN protocol. 79 The 'turn/turns' URI scheme is used to designate a TURN server (also 80 known as a relay) on Internet hosts accessible using the TURN 81 protocol. With the advent of standards such as WEBRTC [WEBRTC], we 82 anticipate a plethora of endpoints and web applications to be able to 83 identify and communicate with such a TURN server to carry out the 84 TURN protocol. This also implies those endpoints and/or applications 85 to be provisioned with appropriate configuration required to identify 86 the TURN server. Having an inconsistent syntax has its drawbacks and 87 can result in non-interoperable solutions. It can result in 88 solutions that are ambiguous and have implementation limitations on 89 the different aspects of the syntax and alike. The 'turn/turns' URI 90 scheme helps alleviate most of these issues by providing a consistent 91 way to describe, configure and exchange the information identifying a 92 TURN server. This would also prevent the shortcomings inherent with 93 encoding similar information in non-uniform syntaxes such as the ones 94 proposed in the WEBRTC Standards [WEBRTC], for example. 96 The 'turn/turns' URI scheme adheres to the generic syntax defined in 97 RFC 3986 [RFC3986]. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 3. URI Scheme Definition 107 3.1. URI Scheme Syntax 109 The 'turn' URI takes the following form (the syntax below is non- 110 normative): 112 turn:@: 114 turns:@: 116 Where with the "@" (at) sign character, as well as the 117 part and the preceding ":" (colon) character, is OPTIONAL. 119 The normative syntax of the 'turn' URI is defined as shown in the 120 following Augmented Backus-Naur Form (ABNF) [RFC5234] rule: 122 turn-uri = turn-scheme ":" [ userinfo "@" ] host [ ":" port ] 123 turn-scheme = "turn"/"turns" 124 userinfo = user [ ":" password ] 125 user = 1*(%x21-24 / %x26-39 / %x3B-3F / %x41-7F 126 / escaped) 127 ; The symbols "%", ":", "@", and symbols 128 ; with a character value below 0x21 may 129 ; be represented as escaped sequences. 130 password = 1*(%x21-24 / %x26-3F / %x41-7F / escaped) 131 ; The symbols "%", "@", and symbols with 132 ; a character value below 0x21 may be 133 ; represented as escaped sequences. 134 host = hostname / IPv4address / IPv6reference 135 hostname = *( domainlabel "." ) toplabel [ "." ] 136 domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum 137 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 138 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 139 IPv6reference = "[" IPv6address "]" 140 IPv6address = hexpart [ ":" IPv4address ] 141 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 142 hexseq = hex4 *( ":" hex4 ) 143 hex4 = 1*4HEXDIG 144 port = 1*DIGIT 145 alphanum = ALPHA / DIGIT 146 escaped = "%" HEXDIG HEXDIG 148 The current ABNF proposal doesn't specify a mechanism for handling 149 different transports. We have identified a possible solution and 150 will be included in the future version of the draft. 152 The , and rules are described in Appendix A 153 of RFC 3986 [RFC3986]. The core rules , and 154 are used as described in Appendix B of RFC 5234 [RFC5234]. 156 3.2. URI Scheme Semantics 158 The TURN protocol supports sending messages over UDP, TCP or TLS- 159 over-TCP. The 'turns' URI scheme SHALL be used when TURN is run over 160 TLS-over-TCP (or in the future DTLS-over-UDP) and the 'turn' scheme 161 SHALL be used otherwise. The part of the 'turn' URI, which is 162 REQUIRED, denotes the TURN server host. The part, 163 identifies the credential required for the long-term credential 164 mechanism as described in the section 10.2 of RFC 5389 [RFC5389]. 165 The part, if present, denotes the port on which the TURN 166 server is awaiting connection requests. If it is absent, the default 167 port SHALL be 3478 for both UDP and TCP. The default port for TURN 168 over TLS SHALL be 5349. 170 4. Examples 172 URI to identify a long-term credential for the TLS-over-TCP 173 connection to TURN server, example.com, on default port 5349: 175 turns:username:password@example.com 177 URI to identify a long-term credential for the connection to TURN 178 server, example.com, on default port 3478: 180 turn:username:password@example.com 182 5. IANA Considerations 184 This document instructs IANA to register the 'turn' and 'turns' URI 185 schemes in the "Permanent URI Schemes" sub-registry in the "Uniform 186 Resource Identifier (URI) Schemes" IANA registry [URIREG]. These 187 registrations follows the URI Scheme Registration Template detailed 188 in Section 5.4 of RFC 4395 [RFC4395]. 190 5.1. The 'turn' URI Scheme Registration 192 IANA registration of the the 'turn' URI scheme: 194 URI scheme name: turn 196 Status: Permanent 198 URI scheme syntax: see Section 3.1 of RFC XXXX [This document] 200 URI scheme semantics: see Section 3.2 of RFC XXXX [This document] 202 URI scheme encoding considerations: there are no other encoding 203 considerations for 'turn' URIs that are not described in RFC 5766 204 [RFC5766]. 206 Protocols that use the scheme: Traversal Using Relays around NAT 207 (TURN) 209 Security Considerations: see Section 6 of RFC XXXX [This document] 211 Contact: IESG 213 Author/Change controller: IETF 215 References: See Section 8 of RFC XXXX [This document] 217 5.2. The 'turns' URI Scheme Registration 219 IANA registration of the the 'turns' URI scheme: 221 URI scheme name: turns 223 Status: Permanent 225 URI scheme syntax: see Section 3.1 of RFC XXXX [This document] 227 URI scheme semantics: see Section 3.2 of RFC XXXX [This document] 229 URI scheme encoding considerations: there are no other encoding 230 considerations for 'turns' URIs that are not described in RFC 5766 231 [RFC5766]. 233 Protocols that use the scheme: Traversal Using Relays around NAT 234 (TURN) when run over TLS-over-TCP. 236 Security Considerations: see Section 6 of RFC XXXX [This document] 238 Contact: IESG 240 Author/Change controller: IETF 242 References: See Section 8 of RFC XXXX [This document] 244 6. Security Considerations 246 The URI Scheme defined by this document for the Traversal Using 247 Relays around NAT (TURN) protocol needs to consider the security 248 considerations detailed in Section 17 of RFC 5766 [RFC5766]. 250 As described in Section 3.2.1 of STD 66 [RFC3986], having 251 authentication information (specifically passwords) in a URI means 252 that the URI must be handled carefully: 254 The passing of authentication information in clear text has proven 255 to be a security risk in almost every case where it has been used. 257 Section 3.2.1 contains advice on handling URI that contain passwords 258 in the userinfo portion. Implementations of this specification MUST 259 implement that advice. 261 Specifically if a URI that contains credentials leaks, then it would 262 allow an attacker to use the TURN server which is referenced by the 263 URI. Such an attack has two major impacts. First, it uses up the 264 operator's bandwidth. Second, if the operator bills the user for 265 TURN server usage, then it may expose the user to costs incurred by 266 the attacker. However, the attacker never obtains the user's private 267 information, nor does this attack allow for traffic amplification. 269 The expected use environment mitigates to some degree concerns about 270 TURN URIs compared to other URIs, such as HTTPS. First, users do not 271 dereference TURN URIs directly. Instead, they are passed to the TURN 272 stack. Thus, concerns about confusion or leakage due to the URI 273 being displayed to the user are significantly reduced; indeed the URI 274 need never be available to the user at all. 276 One of the primary use cases for a TURN URI with credentials is 277 WebRTC. In this case, a web server will be offering a calling 278 service and may have an associated TURN server it can use. In this 279 case, the browser will need to use the TURN server and the browser 280 has no long term or preexisting relationship with the TURN server. 281 The web server needs to provide some credential to the client which 282 it can use to access the TURN server. Since TURN authentication is 283 via username and password, this implies that the credential is a 284 username/password pair. While this must be transmitted securely 285 (i.e., over HTTPS), the security properties are the same whether the 286 password is carried separately or is part of the URL. Moreover, 287 because the web server and TURN servers can cooperate, a new password 288 can be issued for every call, making short-term credentials feasible 289 and thus significantly mitigating the risk. 291 If a TURN URI is transferred between hosts, it MUST be done over a 292 protocol that provides confidentiality such as HTTPS [RFC2818]. It 293 is RECOMMENDED that the credential only be valid for a single call 294 and preferably for no more than one day. that "preferably" is bad. 296 7. Acknowledgements 298 Many thanks to Cullen Jennings for his detailed review and thoughtful 299 comments on this document. 301 We acknowledge the existence of 302 draft-petithuguenin-behave-turn-uri-bis-04 document as a parallel 303 effort in defining the URI scheme for TURN. Awareness of this draft 304 came late in the process and we have not had to time to reach out to 305 the author of that memo and discuss opportunities to collaborate on a 306 single document. It is our intentions to do so. 308 8. References 310 8.1. Normative References 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, March 1997. 315 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 316 Specifications: ABNF", STD 68, RFC 5234, January 2008. 318 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 319 Relays around NAT (TURN): Relay Extensions to Session 320 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 322 8.2. Informative References 324 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 326 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 327 Resource Identifier (URI): Generic Syntax", STD 66, 328 RFC 3986, January 2005. 330 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 331 Registration Procedures for New URI Schemes", BCP 35, 332 RFC 4395, February 2006. 334 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 335 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 336 October 2008. 338 [URIREG] Internet Assigned Numbers Authority (IANA) Registry, 339 "Uniform Resource Identifier (URI) Schemes", 340 . 342 [WEBRTC] W3C, "WebRTC 1.0: Real-time Communication Between 343 Browsers", 344 . 346 Authors' Addresses 348 Suhas Nandakumar 349 Cisco Systems 350 170 West Tasman Drive 351 San Jose, CA 95134 352 US 354 Email: snandaku@cisco.com 356 Gonzalo Salgueiro 357 Cisco Systems 358 7200-12 Kit Creek Road 359 Research Triangle Park, NC 27709 360 US 362 Email: gsalguei@cisco.com 364 Paul E. Jones 365 Cisco Systems 366 7025 Kit Creek Road 367 Research Triangle Park, NC 27709 368 US 370 Email: paulej@packetizer.com