idnits 2.17.1 draft-hethmon-mcmurray-ftpext-ftp-hosts-05.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC959, but the abstract doesn't seem to directly say this. It does mention RFC959 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC959, updated by this document, for RFC5378 checks: 1985-10-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 16, 2014) is 3750 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 informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hethmon 3 Internet-Draft Hethmon Brothers 4 Updates: 959 (if approved) R. McMurray 5 Intended status: Standards Track Microsoft Corporation 6 Expires: July 20, 2014 January 16, 2014 8 File Transfer Protocol HOST Command for Virtual Hosts 9 draft-hethmon-mcmurray-ftpext-ftp-hosts-05 11 Abstract 13 The File Transfer Protocol, as defined in RFC 959, does not provide a 14 way for FTP clients and servers to differentiate between multiple DNS 15 names that are registered for a single IP address. This document 16 defines a new FTP command that provides a mechanism for FTP clients 17 and servers to identify individual virtual hosts on an FTP server. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 20, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Basic Tokens . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Server Replies . . . . . . . . . . . . . . . . . . . . . 4 57 3. The HOST command . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Syntax of the HOST command . . . . . . . . . . . . . . . 5 59 3.2. HOST command semantics . . . . . . . . . . . . . . . . . 8 60 3.2.1. REIN command semantics . . . . . . . . . . . . . . . 9 61 3.2.2. User-PI usage of HOST . . . . . . . . . . . . . . . . 9 62 3.2.3. State Diagrams . . . . . . . . . . . . . . . . . . . 11 63 3.3. HOST command errors . . . . . . . . . . . . . . . . . . . 16 64 3.4. FEAT response for HOST command . . . . . . . . . . . . . 17 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 19 69 6.2. Informative References . . . . . . . . . . . . . . . . . 20 70 Appendix A. Unworkable Alternatives . . . . . . . . . . . . . . 20 71 A.1. Overloading the CWD command . . . . . . . . . . . . . . . 20 72 A.2. Overloading the ACCT command . . . . . . . . . . . . . . 21 73 A.3. Overloading the USER command . . . . . . . . . . . . . . 22 74 A.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 22 75 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 23 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 78 1. Introduction 80 It is common on the Internet for many DNS names to resolve to a 81 single IP address. This practice has introduced the concept of a 82 "virtual host", where a host appears to exist as an independent 83 entity, but in reality shares its physical resources with one or more 84 similar hosts. 86 Such an arrangement presents some problems for FTP servers, because 87 an FTP server distinguishes incoming FTP connections by IP addresses 88 rather than DNS names. Therefore, all DNS names that share a common 89 IP address are handled by the same FTP server and share the same 90 Network Virtual File System (NVFS). 92 This means that different virtual hosts cannot offer different 93 virtual file systems to clients, nor can they offer different 94 authentication systems. Any scheme to overcome this issue needs to 95 indicate not only the destination IP address, but also the virtual 96 host name that is associated with the desired virtual FTP server. 97 Typical user-FTP processes currently use hostnames to perform 98 hostname to IP address resolution and then ignore hostnames for the 99 rest of the FTP session, therefore any mechanism to overcome this 100 issue would require modifications to the user protocol interpreter 101 (user-PI) and server protocol interpreter (server-PI). 103 It should be noted that this same problem existed for HTTP/1.0 as 104 defined in [RFC1945], and was resolved in HTTP/1.1 as defined in 105 [RFC2616] through the addition of the Host request header field. The 106 goal of this document is to bring a similar level of feature parity 107 to FTP by introducing a new HOST command that allows user-FTP 108 processes to specify which virtual host to connect to for a server- 109 FTP process that is handling requests for multiple virtual hosts on a 110 single IP address. 112 2. Document Conventions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 In examples, "C>" and "S>" indicate lines sent by the client and 119 server, respectively. 121 This document also uses notation defined in [RFC0959] and [RFC1123]. 122 In particular, the terms "reply", "user", "NVFS", "NVT", "file", 123 "pathname", "FTP commands", "DTP", "user-FTP process", "user-PI", 124 "user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode", 125 "type", "control connection", "data connection", and "ASCII", are all 126 used here as defined there. 128 Syntax required is defined using the Augmented BNF defined in 129 [RFC5234]. Some general ABNF definitions are required throughout the 130 document; those will be defined in subsequent sections. 132 With the increased use of virtualization technologies, there may be 133 several possible definitions for the term "virtual host." This 134 document follows the definition from section 4.1.14 of [RFC3875], 135 where several virtual hosts share the same IP address, and host names 136 are used by the server-FTP process to route user-PI sessions to the 137 appropriate virtual host. 139 2.1. Basic Tokens 141 This document imports the core definitions given in Appendix B of 142 [RFC5234]. There definitions will be found for basic ABNF elements 143 like ALPHA, DIGIT, SP, etc. To that, the following term is added for 144 use in this document. 146 TCHAR = VCHAR / SP / HTAB ; visible plus white space 148 The VCHAR (from [RFC5234]) and TCHAR rules give basic character types 149 from varying sub-sets of the ASCII character set for use in various 150 commands and responses. 152 Note that in ABNF, string literals are case insensitive. That 153 convention is preserved in this document, and implies that FTP 154 commands and parameters that are added by this specification have 155 values that can be represented in any case. That is, "HOST" is the 156 same as "host", "Host", "HoSt", etc. Similarly, because domain names 157 are defined to be case-insensitive, "ftp.example.com" is the same as 158 "Ftp.Example.Com", "fTp.eXample.cOm", etc. 160 2.2. Server Replies 162 Section 4.2 of [RFC0959] defines the format and meaning of replies by 163 the server-PI to FTP commands from the user-PI. Those reply 164 conventions are used here without change. 166 error-response = error-code SP *TCHAR CRLF 167 error-code = ("4" / "5") 2DIGIT 169 Implementers should note that the ABNF syntax used in this document 170 and other FTP related documents (but which was not used in [RFC0959]) 171 sometimes shows replies using the one line format. Unless otherwise 172 explicitly stated, multi-line responses are also permitted. 173 Implementers should assume that, unless stated to the contrary, any 174 reply to any FTP command (including QUIT) can be of the multi-line 175 format described in [RFC0959]. 177 Throughout this document, replies will be identified by the three- 178 digit code that is their first element. Thus the term "500 reply" 179 means a reply from the server-PI using the three digit code "500". 181 3. The HOST command 183 A new command "HOST" is added to the FTP command set in order to 184 allow a server-FTP process to determine to which of possibly many 185 virtual hosts the client wishes to connect. If a HOST command is 186 sent, it MUST be issued before the user is authenticated, as this 187 will allow the authentication scheme and set of authorized users to 188 be dependent upon the virtual host that is chosen. 190 Server-FTP processes MUST treat a situation where the HOST command is 191 issued more than once before the user has been authenticated as 192 though only the last HOST command had been sent, and return the 193 appropriate reply for the last HOST command. Server-FTP processes 194 MUST treat a situation where the HOST command is issued after the 195 user has been authenticated as an erroneous sequence of commands and 196 return a 503 reply. 198 Servers should note that the response to the HOST command is a 199 sensible time to send their "welcome" message. This allows the 200 message to be personalized for any virtual hosts that are supported. 201 It also allows the client to determine, via the FEAT response, the 202 languages or representations supported by the server, and to select 203 an appropriate one via the LANG command. See [RFC2640] for more 204 information. 206 It should be noted that user-PI implementations that were created 207 before the introduction of the HOST command will not support this new 208 command. A similar problem existed with the introduction of the Host 209 header for HTTP in [RFC2616], and HTTP server implementations had to 210 determine how best to accommodate HTTP requests from down-level 211 clients that did not support the Host header. With this in mind, 212 Server-FTP processes will need to determine how best to accommodate 213 FTP requests from down-level FTP clients that do not support the HOST 214 command, but those considerations are outside the scope of this 215 document. 217 3.1. Syntax of the HOST command 219 The HOST command is defined as follows. Note that [RFC3986] remains 220 the normative specification for the syntactic form of IPv4 and IPv6 221 address literals, in order to ensure identical presentation in 'ftp' 222 URI hostname parts and in the protocol element specified here. 224 host-command = "HOST" SP hostname CRLF 225 hostname = domain / IP-literal 227 domain = sub-domain *("." sub-domain) 228 sub-domain = let-dig [ldh-str] 229 let-dig = ALPHA / DIGIT 230 ldh-str = *( ALPHA / DIGIT / "-" ) let-dig 232 IP-literal = ( "[" IPv6address "]" ) / IPv4address 234 IPv6address = 235 IPv4address = 237 host-response = host-ok / error-response 238 host-ok = "220" [ SP *TCHAR ] CRLF 240 The "hostname" rule is a restricted form of the "host" rule specified 241 in [RFC3986]. Details of the additional restrictions imposed by this 242 document are given further down in this section in the discussion of 243 the syntax; they aim at simplifying implementations by only allowing 244 what currently is specified precisely and in use on the Internet. 246 As with all FTP commands, the "HOST" command word is case 247 independent, and can be specified in any character case desired. 249 The "hostname" (given as a parameter) specifies the virtual host to 250 which access is desired. This SHOULD be the same host name that was 251 used to obtain the IP address to which the FTP control connection was 252 made, after any client conversions have been completed that convert 253 an abbreviated or local alias to a complete (fully qualified) domain 254 name, but before resolving a DNS alias (owner of a CNAME resource 255 record) to its canonical name. 257 Internationalization of domain names is only supported through the 258 use of IDNA "A-Labels" for as described in [RFC5890]. 259 For example, the following HOST command specifies an 260 internationalized domain name: 262 HOST xn--e1afmkfd.com 264 If the user was given an IPv4 or IPv6 literal address, and 265 consequently was not required to derive the literal address from a 266 hostname, the client MAY send the HOST command with the IPv4 or IPv6 267 literal address as specified to it. While it may seem counter- 268 intuitive to specify a literal address by using the HOST command 269 after the client has already connected to the server using a literal 270 address, this should be expected behavior because a user-FTP process 271 should not be required to differentiate between a fully qualified 272 domain name and an IPv4 or IPv6 network literal address. That being 273 said, if the IPv4 or IPv6 literal address specified by the client 274 does not match the literal address for the server, the server MUST 275 respond with a 504 reply to indicate that the IPv4 or IPv6 literal 276 address is not valid. 278 When the hostname parameter contains a literal address, square 279 brackets are expected to disambiguate IPv6 address syntax from port 280 numbers syntax. Therefore, if the literal address is an IPv6 281 address, the IPv6 address is required to be enclosed in square 282 brackets (after eliminating any syntax that might also - but is not 283 required to - be enclosed in brackets, and from which the server 284 deduced that a literal address had been specified.) For example, the 285 following examples MAY be sent if the client had been instructed to 286 respectively connect to "192.0.2.1", "2001:db8::c000:201", or 287 "192.0.2.1" and IPv6 syntax is preferred: 289 HOST 192.0.2.1 290 HOST [2001:db8::c000:201] 291 HOST [::192.0.2.1] 293 The client MUST NOT send the port number as part of the HOST command, 294 even when the client has been instructed to connect to a non-standard 295 port. The reason for this requirement is that the user-PI will have 296 established a connection to the server-PI before the HOST command is 297 sent, therefore specifying a different port with the HOST command has 298 no meaning. For example, the server-PI MUST respond with a 501 reply 299 if the client sends a HOST command with syntax like either of the 300 following examples: 302 HOST 192.0.2.1:2112 303 HOST [2001:db8::c000:201]:2112 305 The hostname parameter is otherwise to be treated as a fully 306 qualified domain name or relative name as those terms are defined in 307 section 3.1 of [RFC1034]. This implies that the name is to be 308 treated as a case-independent string, meaning that uppercase ASCII 309 characters are to be treated as equivalent to their corresponding 310 lowercase ASCII characters, but otherwise preserved as given. It 311 also implies some limits on the length of the parameter and of the 312 components that create its internal structure. Those limits are not 313 altered in any way here. 315 Neither [RFC1034] nor [RFC1035] impose any other restrictions upon 316 what kinds of names can be stored in the DNS. This specification, 317 however, only allows the use of names that can be inferred from the 318 ABNF grammar given for the "hostname". Similarly, this specification 319 restricts address literals to the IPv4 and IPv6 address families well 320 established in the Internet. 322 3.2. HOST command semantics 324 Upon receiving the HOST command, before authenticating the user-PI, a 325 server-FTP process SHOULD validate that the hostname given represents 326 a valid virtual host for that server, and, if it is valid, establish 327 the appropriate environment for that virtual host. The resultant 328 actions needed to create that environment are not specified here, and 329 may range from doing nothing at all, to performing a simple change of 330 working directory, changing authentication schemes and/or username 331 and password lists, or making much more elaborate state changes - 332 such as creating isolated environments for each FTP session. 334 The "220" reply code for the HOST command is the same as the code 335 that is used in the initial "welcome" message that is sent after the 336 connection is established. 338 If the hostname specified would normally be acceptable, but is 339 temporarily unavailable, the server-FTP process SHOULD reply to the 340 HOST command with a 421 reply and close the connection. 342 Example: 344 The server-FTP process is shutting down, so the server-FTP process 345 responds to the HOST command with a 421 reply and closes the 346 connection. In this scenario, the 421 reply informs the client it 347 can retry at another time. 349 If the hostname specified is unknown at the server, or if the server 350 is otherwise unwilling to treat the particular connection as a 351 connection to the hostname specified, the server SHOULD respond with 352 a 504 reply. 354 Examples: 356 The particular virtual host that was specified by the HOST command 357 is disabled at the server. The server responds with a 504 reply, 358 and keeps the connection open in order to allow the user-PI an 359 opportunity to specify another virtual host with a subsequent HOST 360 command. 362 Alternatively, the server-FTP process might choose to route all 363 connections with unknown hostnames to a different virtual host so 364 that no connection attempts will result in failed connections. 365 This design would be implementation-specific and outside the scope 366 of this specification. 368 3.2.1. REIN command semantics 370 As specified in [RFC0959], the REIN command returns the state of the 371 connection to what it was immediately after the transport connection 372 was opened. This specification makes no changes to that behavior. 373 The effect of a HOST command MUST be reset if a REIN command is 374 performed, and a new HOST command MUST be issued afterwards in order 375 to connect to a virtual host. 377 3.2.2. User-PI usage of HOST 379 A user-PI MUST send the HOST command after opening the transport 380 connection, or after any REIN command, before attempting to 381 authenticate the user with the USER command. The following example 382 illustrates what a typical login sequence might look like when the 383 HOST command is used: 385 C> HOST ftp.example.com 386 S> 220 Host accepted 387 C> USER foo 388 S> 331 Password required 389 C> PASS bar 390 S> 230 User logged in 392 If a user-PI sends an additional HOST command before attempting to 393 authenticate the user, a server-FTP process MUST treat the additional 394 HOST command as though a previous HOST command was not sent, and 395 return the appropriate reply for the new HOST command. For example, 396 if a user specifies the wrong virtual host by mistake, sending a 397 subsequent HOST command will rectify the error. The following 398 example illustrates what the login sequence might look like when the 399 HOST command is sent twice before a user has been authenticated: 401 C> HOST foo.example.com 402 S> 220 Host accepted 403 C> HOST bar.example.com 404 S> 220 Host accepted 405 C> USER foo 406 S> 331 Password required 407 C> PASS bar 408 S> 230 User logged in 410 The HOST command can be used in combination with the ACCT command to 411 differentiate between a user's various accounts on a specific virtual 412 host. In this scenario, the user-PI sends a HOST command which the 413 server-PI uses to route activity to the correct virtual host; the 414 user-PI sends credentials using the USER and PASS commands which the 415 server-PI validates; then, the user-PI sends an ACCT command to 416 specify any additional account information for the server-PI 417 implementation. The following example illustrates a sequential 418 series of client commands that specify both a HOST and ACCT, with the 419 server responses omitted for brevity: 421 C> HOST ftp.example.com 422 C> USER foo 423 C> PASS bar 424 C> ACCT project1 426 This is also true when the HOST command is used with the AUTH and 427 ADAT commands that are discussed in [RFC2228] and [RFC4217]. In this 428 scenario, the user-PI sends a HOST command which the server-PI uses 429 to route activity to the correct virtual host, then the user-PI uses 430 the AUTH and ADAT commands to negotiate the security mechanism and 431 relevant authentication token(s) with the server-PI, then the user-PI 432 sends user credentials using the USER and PASS commands which the 433 server-PI validates. After which the user-PI MAY send an ACCT 434 command to specify any additional account information for the server- 435 PI implementation. The following example illustrates a sequential 436 series of client commands that specify both HOST and ACCT commands 437 when used in conjunction with the security commands that are 438 discussed in [RFC2228] and [RFC4217], with the server responses 439 omitted for brevity: 441 C> HOST ftp.example.com 442 C> AUTH 443 C> ADAT 444 C> USER foo 445 C> PASS bar 446 C> ACCT project1 448 An exception to the above scenario would be when a user-PI is 449 providing the hostname in the "server_name" extension of a TLS 450 extended client hello as discussed in [RFC6066]. When the user-PI 451 specifies the hostname in the "server_name" extension of a TLS 452 extended client hello, the server-PI MUST verify that the hostname in 453 the HOST command matches the value of the "server_name" extension. 454 The following example illustrates a sequential series of client 455 commands that specify the HOST command when used in conjunction with 456 the TLS extensions that are discussed in [RFC6066], with the server 457 responses omitted for brevity: 459 C> AUTH TLS 460 C> HOST ftp.example.com 461 C> USER foo 462 C> PASS bar 464 Additional security information about using the HOST command with the 465 security extensions that are discussed in [RFC2228], [RFC4217], and 466 [RFC6066] is provided in Section 4 of this document. 468 3.2.3. State Diagrams 470 The state diagrams in this section illustrate typical sequences for 471 command and reply interchange between the user-PI and server-PI. 472 These diagrams are modeled on the similar diagrams in section 6 of 473 [RFC0959]. 475 In each diagram, the (B) "begin" state is assumed to occur after the 476 transport connection has opened, or after a REIN command has 477 succeeded. Other commands (such as FEAT [RFC2389]) that require no 478 authentication may have intervened. 480 Additionally, a three-digit reply indicates a precise server reply 481 code. A single digit on a reply path indicates any server reply that 482 begins with that digit, except where a precise server reply code is 483 defined on another path. For example, a single digit "5" will apply 484 to "500", "501", "502", etc., when those reply codes are not 485 expressly defined in the diagram. For each command there are three 486 possible outcomes: success (S), failure (F), and error (E). In the 487 state diagrams below we use the symbol B for "begin", and the symbol 488 W for "wait for reply". 490 For each of these diagrams, without any state transitions being 491 shown, a REIN command will return the diagram from any wait state to 492 the (B) "begin" state. 494 The state diagram in Figure 1 shows a typical sequence of flow of 495 control when HOST is used with USER and PASS to log in to a 496 particular FTP virtual host. 498 +---+ HOST +---+ 1,3,5 499 | B |---------->| W |----------------- 500 +---+ +---+ | 501 | | | 502 2,500,502 | | 4,501,503,504 | 503 -------------- ----------- | 504 | | V 505 V 1 | +---+ 506 +---+ USER +---+-------------->| E | 507 | |---------->| W | 2 | +---+ 508 +---+ +---+------- | ^ 509 | | | | | 510 3 | | 4,5 | | | 511 -------------- ----- | | | 512 | | | | | 513 | ------------------- 514 | 1| | | | 515 V | | ------>+---+ 516 +---+ PASS +---+ 2 | | | S | 517 | |---------->| W |-------------->+---+ 518 +---+ +---+ | | 519 | | | 520 |4,5 | | 521 | | --->+---+ 522 | --------->| F | 523 ---------------->+---+ 525 Figure 1: Typical login sequence with HOST command 527 After a user has logged in, an additional account may be required by 528 the server and specified by the client by using ACCT command. With 529 this in mind, the state diagram in Figure 2 shows a typical sequence 530 of flow of control when HOST is used with USER and PASS to log in to 531 an FTP virtual host and ACCT is used to specify an account. 533 +---+ HOST +---+ 1,3,5 534 | B |---------->| W |----------------- 535 +---+ +---+ | 536 | | | 537 2,500,502 | | 4,501,503,504 | 538 -------------- ------------- | 539 | | | 540 V 1 | V 541 +---+ USER +---+-------------->+---+ 542 | |---------->| W | 2 ----->| E | 543 +---+ +---+------ | --->+---+ 544 | | | | | | 545 3 | | 4,5 | | | | 546 -------------- ----- | | | | 547 | | | | | | 548 | | | | | | 549 | ---------- | | 550 | 1| | | | | 551 V | | | | | 552 +---+ PASS +---+ 2 | ------->+---+ 553 | |---------->| W |-------------->| S | 554 +---+ +---+ ----------->+---+ 555 | | | | | | 556 3 | |4,5| | | | 557 -------------- -------- | ---- 558 | | | | | | 559 | | | | | | 560 | ------------ | 561 | 1,3| | | | | 562 V | 2| | | V 563 +---+ ACCT +---+-- | ------>+---+ 564 | |---------->| W | 4,5 --------->| F | 565 +---+ +---+-------------->+---+ 567 Figure 2: Login sequence with HOST and ACCT commands 569 The state diagram in Figure 3 shows a typical sequence of flow of 570 control when HOST is used with the AUTH and ADAT commands that are 571 discussed in [RFC2228]. (NOTE: Section 4 provides additional 572 information about using the HOST command with TLS.) 573 +---+ HOST +---+ 1,3,5 574 | B |---------->| W |------------------ 575 +---+ +---+ | 576 | | | 577 2,500,502 | | 4,501,503,504 | 578 -------------- ------------- | 579 | | | 580 V | | 581 +---+ AUTH +---+ 4,5 | | 582 | |---------->| W |----------->| | 583 +---+ +---+ | | 584 334 | | | | 585 -------------- | | | 586 | 234 | | | 587 | ------------ | | 588 V | 4,5 | | 589 +---+ | ADAT +---+----------->| | 590 | |---------->| W | 335 | | 591 +---+ | +---+----- | | 592 ^ | | | | | 593 | | | | | | 594 ----------------------- | | 595 | | | | 596 ---- 235 | | | 597 | -------------- | | 598 | | | V 599 V V 1 | +---+ 600 +---+ USER +---+--------------->| E | 601 | |---------->| W | 2 | +---+ 602 +---+ +---+------- | ^ 603 | | | | | 604 3 | | 4,5 | | | 605 -------------- ------ | | | 606 | | | | | 607 | -------------------- 608 | 1| | | | 609 V | | ------->+---+ 610 +---+ PASS +---+ 2 | | | S | 611 | |---------->| W |--------------->+---+ 612 +---+ +---+ | | 613 | | | 614 |4,5 | | 615 | | -->+---+ 616 | --------->| F | 617 ----------------->+---+ 619 Figure 3: Login sequence with HOST and AUTH/ADAT commands 621 After a user has logged in with the security commands that are 622 discussed in [RFC2228], an additional account may be required by the 623 server and specified by the client by using ACCT command. The state 624 diagram in Figure 4 shows a typical sequence of flow of control when 625 HOST is used with the AUTH and ADAT commands to log in to an FTP 626 virtual host and ACCT is used to specify an account. 628 +---+ HOST +---+ 1,3,5 629 | B |---------->| W |------------------ 630 +---+ +---+ | 631 | | | 632 2,500,502 | | 4,501,503,504 | 633 +-------------- -------------- | 634 | | | 635 V | | 636 +---+ AUTH +---+ 4,5 | | 637 | |---------->| W |------------>| | 638 +---+ +---+ | | 639 334 | | | | 640 -------------- | | | 641 | 234 | | | 642 | ------------ | | 643 V | 4,5 | | 644 +---+ | ADAT +---+------------>| | 645 | |---------->| W | 335 | | 646 +---+ | +---+----- | | 647 ^ | | | | | 648 | | | | | | 649 ----------------------- | | 650 | | | | 651 ---- 235| | | 652 | -------------- | | 653 | | | | 654 V V 1 | V 655 +---+ USER +---+--------------->+---+ 656 | |---------->| W | 2 ----->| E | 657 +---+ +---+------- | --->+---+ 658 | | | | | | 659 3 | | 4,5 | | | | 660 -------------- ------ | | | | 661 | | | | | | 662 | ----------- | | 663 | 1| | | | | 664 V | | | | | 665 +---+ PASS +---+ 2 | ------->+---+ 666 | |---------->| W |--------------->| S | 667 +---+ +---+ ------------>+---+ 668 | | | | | | 670 3 | |4,5| | | | 671 -------------- --------- | ---- 672 | | | | | | 673 | ------------- | 674 | 1,3| | | | | 675 V | 2| | | V 676 +---+ ACCT +---+-- | ------>+---+ 677 | |---------->| W | 4,5 --------->| F | 678 +---+ +---+--------------->+---+ 680 Figure 4: Login sequence with HOST and AUTH/ADAT/ACCT commands 682 3.3. HOST command errors 684 The server-PI SHOULD return a 500 or 502 reply if the HOST command is 685 unrecognized or unimplemented, as specified in [RFC0959]. For 686 example, a server-PI that predates or otherwise does not conform to 687 this specification would be expected to return a 500 or 502 reply. 689 As discussed in section 3 of this document, if a HOST command is sent 690 after a user has been authenticated, the server MUST treat the 691 situation as an invalid sequence of commands and return a 503 reply. 693 A 501 reply SHOULD be sent if the hostname given is syntactically 694 invalid, and a 504 reply SHOULD be sent if a syntactically valid 695 hostname is not a valid virtual host name for the server. In all 696 such cases, the server-FTP process MUST do one of the following: 698 a. Ignore the HOST command and act as if a HOST command had not been 699 sent. A user-FTP process MAY then send a subsequent HOST command 700 with a different hostname. 702 b. Close the connection. 704 A user-PI receiving a 500 or 502 reply to a HOST command SHOULD 705 assume that the server-PI does not implement virtual servers by using 706 the HOST command. The user-PI MAY then proceed to login as if the 707 HOST command had not been sent. 709 A user-PI receiving an error reply that is different from the errors 710 that have been described here SHOULD assume that the virtual HOST is 711 unavailable, and terminate communications. 713 A server-PI that receives a USER command to begin the authentication 714 sequence without having received a HOST command SHOULD NOT reject the 715 USER command. Clients which conform to earlier FTP specifications do 716 not send HOST commands. In this case the server MAY act as if some 717 default virtual host had been explicitly selected, or MAY enter an 718 environment that is different from that of any supported virtual 719 hosts, perhaps one in which a union of all available accounts exists 720 and which presents an NVFS that appears to contain subdirectories 721 that contain the NVFS for all supported virtual hosts. 723 3.4. FEAT response for HOST command 725 When replying to the FEAT command [RFC2389], a server-FTP process 726 that supports the HOST command MUST include a line containing the 727 single word "HOST". This word is case insensitive, but it SHOULD be 728 sent in upper case so as to maximize interoperability with disparate 729 implementations. That is, the response SHOULD be: 731 C> FEAT 732 S> 211- 733 S> ... 734 S> HOST 735 S> ... 736 S> 211 End 738 The ellipses indicate place holders where other features may be 739 included, and are not required. The one-space indentation of the 740 feature lines is mandatory [RFC2389]. 742 4. Security Considerations 744 As discussed in section 3 of this document, a server implementation 745 MUST treat an additional HOST command that was sent before a user has 746 been authenticated as though a previous HOST command was not sent. 747 In this situation, the server implementation MUST reset the 748 authentication environment, as that would allow for segregation 749 between the security environments for each virtual host on an FTP 750 server. The implementation details for security environments may 751 vary greatly based on the requirements of each server implementation 752 and operating system, and those details are outside the scope of the 753 protocol itself. For example, a virtual host "foo.example.com" on an 754 FTP server might use a specific username and password list, while the 755 virtual host "bar.example.com" on the same FTP server might use a 756 different username and password list. In such a scenario, resetting 757 the security environment is necessary for the virtual servers to 758 appear to behave independently from a client perspective, while the 759 actual server implementation details are irrelevant at the protocol 760 level. 762 Section 15.1.1 of [RFC4217] discusses the use of X.509 certificates 763 for server authentication. Taking the information from that document 764 into account, when securing FTP sessions with the security mechanisms 765 that are defined in [RFC4217], client implementations SHOULD verify 766 that the hostname which they specify in the parameter for the HOST 767 command matches the identity that is specified in the server's X.509 768 certificate in order to prevent man-in-the-middle attacks. 770 When the HOST command is used in combination with the FTP security 771 extensions that were introduced in [RFC2228] and [RFC4217], the HOST 772 command SHOULD precede the security handshake when the user-PI is not 773 providing the "server_name" in the extended client hello as defined 774 in [RFC6066]. This allows both user-FTP and server-FTP processes to 775 map an FTP HOST with the correct server name in the server's 776 certificate. If the HOST command is sent after the security 777 handshake, then mapping an FTP HOST to the correct security 778 certificate will not take place before the secure session is 779 established. 781 For example, if a server-FTP process has multiple virtual hosts 782 defined and no hostname has been sent from a user-FTP process, the 783 server-FTP process will be unable to route the connection to the 784 correct virtual host when the connection is established. In this 785 situation, the server-FTP process will be forced to choose a virtual 786 host that will respond. When the user-PI attempts to negotiate a 787 secure connection, the virtual host to which the connection was 788 routed will respond with its server certificate during the security 789 handshake. If the virtual host that was chosen by the server-FTP 790 process does not match the virtual host to which the user-FTP process 791 had intended to connect, the user-PI will be unable to verify the 792 server's identity as presented in the server certificate message. 794 However, if the user-PI is providing the "server_name" in the 795 extended client hello as defined in Section 3 of [RFC6066], the user- 796 PI MAY provide the HOST command after the security handshake because 797 the server will be able to route the connection to the correct 798 virtual host based on the contents of the "server_name" extension and 799 the client will be able to verify the server's identity as presented 800 in the corresponding server certificate message. However, the 801 server-PI MUST verify that the name in the HOST command matches the 802 "server_name" that is provided in the extended client hello. 804 In general, client implementations SHOULD protect user credentials by 805 using the FTP security extensions that were introduced in [RFC2228] 806 and [RFC4217]; a detailed discussion for securing FTP sessions can be 807 found in those documents, and a general discussion of security issues 808 related to FTP can be found in [RFC2577]. 810 5. IANA Considerations 812 IANA is requested to register the following FTP extension according 813 to the procedure established by [RFC5797]: 815 +------+---------+-------------+------+------+----------------------+ 816 | cmd | FEAT | description | type | conf | RFC#s/References and | 817 | | Code | | | | Notes | 818 +------+---------+-------------+------+------+----------------------+ 819 | HOST | HOST | Hostname | a | o | TBD | 820 +------+---------+-------------+------+------+----------------------+ 822 NOTE TO RFC EDITOR: Please update TBD in the above table with the 823 number of this document. 825 6. References 827 6.1. Normative References 829 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol 830 (FTP)", STD 9, RFC 959, October 1985. 832 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 833 STD 13, RFC 1034, November 1987. 835 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 836 Specification", STD 13, RFC 1035, November 1987. 838 [RFC1123] Braden, R., "Requirements for Internet Hosts -- 839 Application and Support", STD 3, RFC 1123, October 1989. 841 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 842 Requirement Levels", BCP 14, RFC 2119, March 1997. 844 [RFC2228] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 845 2228, October 1997. 847 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 848 the File Transfer Protocol", RFC 2389, August 1998. 850 [RFC2640] Curtin, W., "Internationalization of the File Transfer 851 Protocol", RFC 2640, July 1999. 853 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 854 Resource Identifier (URI): Generic Syntax", RFC 3986, 855 January 2005. 857 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 858 October 2005. 860 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 861 Specifications: ABNF", RFC 5234, January 2008. 863 [RFC5890] Klensin, J., "Internationalized Domain Names for 864 Applications (IDNA): Definitions and Document Framework", 865 RFC 5890, August 2010. 867 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 868 Extension Definitions", RFC 6066, January 2011. 870 6.2. Informative References 872 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 873 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 875 [RFC2577] Allman, M. and S. Ostermann, "FTP Security 876 Considerations", RFC 2577, May 1999. 878 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 879 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 880 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 882 [RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface 883 (CGI) Version 1.1", RFC 3875, October 2004. 885 [RFC5797] Klensin, J. and A. Hoenes, "FTP Command and Extension 886 Registry", RFC 5797, March 2010. 888 Appendix A. Unworkable Alternatives 890 Due to the level of scope for adding a new command to FTP, a brief 891 discussion of suggested alternatives to a HOST command and their 892 respective limitations is warranted. The suggested alternatives that 893 are discussed in this appendix have been proposed in the past, but 894 each of these ideas was deemed insufficient for the reasons that are 895 listed within each section of the appendix. 897 A.1. Overloading the CWD command 899 One suggested method to emulate a form of virtual hosts would be for 900 the client to simply send a "CWD" command after connecting, using the 901 virtual host name as the argument to the CWD command. This would 902 allow the server-FTP process to implement the file stores of the 903 virtual hosts as sub-directories in its NVFS. This suggestion is 904 simple in concept, and most server-FTP implementations support this 905 without requiring any code changes. While this method is simple to 906 describe, and to implement, it suffers from several drawbacks: 908 a. The "CWD" command is available only after the user-PI has 909 authenticated itself to the server-FTP process. Thus, all 910 virtual hosts would be required to share a common authentication 911 scheme if they used this method. 913 b. To make the virtual host truly transparent, either the server-FTP 914 process needs to be modified to include information that shows 915 the special nature of this first CWD command (negating most of 916 the advantage of this scheme), or all users must see the same 917 identical NVFS view upon connecting (they must connect in the 918 same initial directory), or the NVFS must implement the full set 919 of virtual host directories at each possible initial directory 920 for any possible user. 922 c. Unless the server is specially modified, a user connecting this 923 way to a virtual host would be able to easily move to any other 924 virtual host supported at the same server-FTP process, exposing 925 the nature of the virtual host. 927 A.2. Overloading the ACCT command 929 Another suggested method would be to simply overload the "ACCT" for 930 FTP virtual hosts, but this proposal is unacceptable for several 931 reasons with regard to when the ACCT command is sent during the 932 request flow. Sections 5.4 and 6 of [RFC0959] document the request 933 flow for a login sequence as USER -> PASS -> ACCT. This flow of 934 commands may be acceptable when you are considering a single user 935 having multiple accounts on an FTP server, but fails to differentiate 936 between virtual hosts when you consider the following two issues: 938 a. The first problem with overloading the ACCT command is 939 certificate negotiation when using the FTP security extensions 940 that are documented in [RFC2228] and [RFC4217]. In order to 941 safeguard user credentials, security mechanism and certificate 942 negotiation must occur before login credentials are sent by the 943 client. The problem with using the ACCT command in this scenario 944 is that there is no way of ensuring that the certificate matches 945 the correct virtual host before the user credentials are sent. 947 b. The second problem with overloading the ACCT command is how user 948 credentials are implemented for FTP virtual hosts. FTP server 949 implementations may allow the use of custom user credentials on a 950 per-virtual-host basis. For example, in one particular 951 implementation the virtual host negotiation occurs, and then the 952 user credentials are looked up using the account mechanism that 953 is specific to that virtual host. So once again the virtual host 954 negotiation must take place before the user credentials are sent. 956 A.3. Overloading the USER command 958 An additional suggestion would be to overload well-known syntax 959 through the existing USER command, as illustrated in the following 960 example: 962 C> USER foo@example.com 963 S> 331 Password required 964 C> PASS bar 965 S> 230 User logged in 967 In this example, the user "foo" might be attempting to log on to the 968 virtual host "example.com" on an FTP server. This suggestion may 969 seem plausible at first, but introduces several implementation 970 problems. For example: 972 a. Some network environments already use the "username@hostname" 973 syntax for network credentials, where the "hostname" portion 974 refers to the location of the user's credentials within the 975 network hierarchy. Using the "foo@example.com" syntax it becomes 976 difficult to differentiate between the user "foo" logging into a 977 virtual host named "example.com" on an FTP server versus the user 978 "foo@example.com" logging into an FTP server with no specified 979 virtual host. 981 b. When using the FTP security extensions that are documented in 982 [RFC2228] and [RFC4217], security mechanism and certificate 983 negotiation must occur before login credentials are sent by the 984 client. More specifically, the AUTH/ADAT commands must be sent 985 before the USER command in order to safeguard user credentials. 986 If you overload the USER command, there is no way of ensuring 987 that the certificate matches the correct virtual host before the 988 user credentials are sent by the client. 990 A.4. Conclusion 992 After examining the above alternatives, and in order to obtain an 993 adequate emulation of "real" FTP servers, it was concluded that 994 supporting virtual hosts will require both client and server 995 modifications. Therefore a new FTP command seems the most likely 996 solution to provide the required level of support. 998 Appendix B. Acknowledgements 1000 Robert Elz and Paul Hethmon provided a detailed discussion of the 1001 HOST command in their Internet draft titled "Extensions to FTP" as 1002 part of their work with the FTPEXT Working Group at the IETF. Their 1003 work formed the basis for much of this document, and their help has 1004 been greatly appreciated. They would also like to credit Bernhard 1005 Rosenkraenzer for having first suggested and described the HOST 1006 command. 1008 Several people have provided a wealth of constructive feedback about 1009 earlier versions of this document that have helped to shape its 1010 development; many of their suggestions have been incorporated, and 1011 their contributions are gratefully acknowledged. There are far too 1012 many to mention here, but authors of this document would like to 1013 specifically thank Alexey Melnikov, Alfred Hoenes, John Klensin, Joe 1014 Touch, Paul Ford-Hutchinson, Daniel Stenberg, Mykyta Yevstifeyev, 1015 Alec Rowell, Anthony Bryan, and Barry Leiba for their assistance. 1017 Authors' Addresses 1019 Paul Hethmon 1020 Hethmon Brothers 1021 2305 Chukar Road 1022 Knoxville, TN 37923 1023 USA 1025 Email: phethmon@hethmon.com 1027 Robert McMurray 1028 Microsoft Corporation 1029 One Microsoft Way 1030 Redmond, WA 98052 1031 USA 1033 Email: robmcm@microsoft.com