idnits 2.17.1 draft-ietf-ftpext2-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 abstract seems to contain references ([RFC0959]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- 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 (December 7, 2011) is 4523 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: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FTPEXT2 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: June 9, 2012 December 7, 2011 8 File Transfer Protocol HOST Command for Virtual Hosts 9 draft-ietf-ftpext2-hosts-05 11 Abstract 13 The File Transfer Protocol, as defined in RFC 959 [RFC0959], does not 14 provide a way for FTP clients and servers to differentiate between 15 multiple DNS names that are registered for a single IP address. This 16 document defines a new FTP command that provides a mechanism for FTP 17 clients and servers to identify individual virtual hosts on an FTP 18 server. 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 June 9, 2012. 37 Copyright Notice 39 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Basic Tokens . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Server Replies . . . . . . . . . . . . . . . . . . . . . . 4 58 3. The HOST command . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Syntax of the HOST command . . . . . . . . . . . . . . . . 5 60 3.2. HOST command semantics . . . . . . . . . . . . . . . . . . 8 61 3.2.1. REIN command semantics . . . . . . . . . . . . . . . . 8 62 3.2.2. User-PI usage of HOST . . . . . . . . . . . . . . . . 9 63 3.2.3. State Diagrams . . . . . . . . . . . . . . . . . . . . 10 64 3.3. HOST command errors . . . . . . . . . . . . . . . . . . . 16 65 3.4. FEAT response for HOST command . . . . . . . . . . . . . . 17 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 70 6.2. Informative References . . . . . . . . . . . . . . . . . . 19 71 Appendix A. Unworkable Alternatives . . . . . . . . . . . . . . . 19 72 A.1. Overloading the CWD command . . . . . . . . . . . . . . . 19 73 A.2. Overloading the ACCT command . . . . . . . . . . . . . . . 20 74 A.3. Overloading the USER command . . . . . . . . . . . . . . . 21 75 A.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 21 76 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 21 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 79 1. Introduction 81 It is common on the Internet for many DNS names to resolve to a 82 single IP address. This practice has introduced the concept of a 83 "virtual host", where a host appears to exist as an independent 84 entity, but in reality shares its physical resources with one or more 85 similar hosts. 87 Such an arrangement presents some problems for FTP servers, as an FTP 88 server distinguishes incoming FTP connections by their IP addresses, 89 not their DNS names, because hosts are uniquely identified by their 90 address rather than name. That is, all DNS names that share an IP 91 address are handled by the same FTP server and share the same Network 92 Virtual File System (NVFS). 94 This means that different virtual hosts cannot offer different 95 virtual file systems to clients, nor can they offer different 96 authentication systems. Any scheme to overcome this issue needs to 97 indicate not only the destination IP address, but also the virtual 98 host name that is associated with the desired virtual FTP server. 99 Typical user-FTP processes currently use hostnames to perform 100 hostname to IP address resolution and then ignore hostnames for the 101 rest of the FTP session, therefore any mechanism to overcome this 102 issue would require modifications to the user-PI and server-PI. 104 It should be noted that this same problem existed for HTTP/1.0 as 105 defined in [RFC1945], and was resolved in HTTP/1.1 as defined in 106 [RFC2616] through the addition of the Host request header. The goal 107 of this document is to bring a similar level of feature parity to FTP 108 by introducing a new HOST command that allows user-FTP processes to 109 specify which virtual host to connect to for a server-FTP process 110 that is handling requests for multiple virtual hosts on a single IP 111 address. 113 2. Document Conventions 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 In examples, "C>" and "S>" indicate lines sent by the client and 120 server, respectively. 122 This document also uses notation defined in [RFC0959] and [RFC1123]. 123 In particular, the terms "reply", "user", "NVFS", "NVT", "file", 124 "pathname", "FTP commands", "DTP", "user-FTP process", "user-PI", 125 "user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode", 126 "type", "control connection", "data connection", and "ASCII", are all 127 used here as defined there. 129 Syntax required is defined using the Augmented BNF defined in 130 [RFC5234]. Some general ABNF definitions are required throughout the 131 document; those will be defined later in this section. At first 132 reading, it may be wise to simply recall that these definitions exist 133 here, and skip to the next section. 135 2.1. Basic Tokens 137 This document imports the core definitions given in Appendix B of 138 [RFC5234]. There definitions will be found for basic ABNF elements 139 like ALPHA, DIGIT, SP, etc. To that, the following term is added for 140 use in this document. 142 TCHAR = VCHAR / SP / HTAB ; visible plus white space 144 The VCHAR (from [RFC5234]) and TCHAR rules give basic character types 145 from varying sub-sets of the ASCII character set for use in various 146 commands and responses. 148 Note that in ABNF, string literals are case insensitive. That 149 convention is preserved in this document, and implies that FTP 150 commands and parameters that are added by this specification have 151 values that can be represented in any case. That is, "HOST" is the 152 same as "host", "Host", "HoSt", etc., and "ftp.example.com" is the 153 same as "Ftp.Example.Com", "fTp.eXample.cOm", etc. 155 2.2. Server Replies 157 Section 4.2 of [RFC0959] defines the format and meaning of replies by 158 the server-PI to FTP commands from the user-PI. Those reply 159 conventions are used here without change. 161 error-response = error-code SP *TCHAR CRLF 162 error-code = ("4" / "5") 2DIGIT 164 Implementers should note that the ABNF syntax (which was not used in 165 [RFC0959]) used in this document, and other FTP related documents, 166 sometimes shows replies using the one line format. Unless otherwise 167 explicitly stated, that is not intended to imply that multi-line 168 responses are not permitted. Implementers should assume that, unless 169 stated to the contrary, any reply to any FTP command (including QUIT) 170 can be of the multi-line format described in [RFC0959]. 172 Throughout this document, replies will be identified by the three 173 digit code that is their first element. Thus the term "500 reply" 174 means a reply from the server-PI using the three digit code "500". 176 3. The HOST command 178 A new command "HOST" is added to the FTP command set to allow the 179 server-FTP process to determine to which of possibly many virtual 180 hosts the client wishes to connect. This command MUST be issued 181 before the user is authenticated, allowing the authentication scheme, 182 and set of legal users, to be dependent upon the virtual host chosen. 184 Server-FTP processes that conform to this specification MUST treat a 185 situation where the HOST command is issued more than once before the 186 user has been authenticated as though a previous HOST command was not 187 sent, and return the appropriate reply for the new HOST command. 188 Server-FTP processes MUST treat a situation where the HOST command is 189 issued after the user has been authenticated as an erroneous sequence 190 of commands and return a 503 reply. 192 Servers should note that the response to the HOST command is a 193 sensible time to send their "welcome" message. This allows the 194 message to be personalized for any virtual hosts that are supported, 195 and also allows the client to determine the supported languages, or 196 representations, for the message, and other messages, via the FEAT 197 response, and select an appropriate one via the LANG command. See 198 [RFC2640] for more information. 200 3.1. Syntax of the HOST command 202 The HOST command is defined as follows. 204 host-command = "HOST" SP hostname CRLF 205 hostname = domain / IP-literal 207 domain = sub-domain *("." sub-domain) 208 sub-domain = let-dig [ldh-str] 209 let-dig = ALPHA / DIGIT 210 ldh-str = *( ALPHA / DIGIT / "-" ) let-dig 212 IP-literal = ( "[" IPv6address "]" ) / IPv4address 214 IPv6address = 6( h16 ":" ) ls32 215 / "::" 5( h16 ":" ) ls32 216 / [ h16 ] "::" 4( h16 ":" ) ls32 217 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 218 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 219 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 220 / [ *4( h16 ":" ) h16 ] "::" ls32 221 / [ *5( h16 ":" ) h16 ] "::" h16 222 / [ *6( h16 ":" ) h16 ] "::" 224 ls32 = ( h16 ":" h16 ) / IPv4address 225 ; least-significant 32 bits of address 227 h16 = 1*4HEXDIG 228 ; 16 bits of address represented in hexadecimal 230 IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet 232 dec-octet = DIGIT ; 0-9 233 / %x31-39 DIGIT ; 10-99 234 / "1" 2DIGIT ; 100-199 235 / "2" %x30-34 DIGIT ; 200-249 236 / "25" %x30-35 ; 250-255 238 host-response = host-ok / error-response 239 host-ok = "220" [ SP *TCHAR ] CRLF 241 As with all FTP commands, the "HOST" command word is case 242 independent, and MAY be specified in any character case desired. 244 The "hostname" (given as a parameter) specifies the virtual host to 245 which access is desired. This SHOULD be the same host name that was 246 used to obtain the IP address to which the FTP control connection was 247 made, after any client conversions have been completed that convert 248 an abbreviated or local alias to a complete (fully qualified) domain 249 name, but before resolving a DNS alias (owner of a CNAME resource 250 record) to its canonical name. 252 Internationalization of domain names is only supported through the 253 use of Punycode as described in [RFC3492]. 255 If the user was given an IPv4 or IPv6 literal address, and 256 consequently was not required to derive the literal address from a 257 hostname, the client MAY send the HOST command with the IPv4 or IPv6 258 literal address as specified to it. While it may seem counter- 259 intuitive to specify a literal address by using the HOST command 260 after the client has already connected to the server using a literal 261 address, this should be expected behavior because a user-FTP process 262 should not be required to differentiate between a fully qualified 263 domain name and an IPv4 or IPv6 network literal address. That being 264 said, if the IPv4 or IPv6 literal address specified by the client 265 does not match the literal address for the server, the server MUST 266 respond with a 504 reply to indicate that the IPv4 or IPv6 literal 267 address is not valid. 269 When the hostname parameter contains a literal address, square 270 brackets are expected to disambiguate IPv6 address syntax from port 271 numbers syntax. Therefore, if the literal address is an IPv6 272 address, the IPv6 address is required to be enclosed in square 273 brackets (after eliminating any syntax that might also - but is not 274 required to - be enclosed in brackets, and from which the server 275 deduced that a literal address had been specified.) For example, the 276 following examples MAY be sent if the client had been instructed to 277 respectively connect to "192.0.2.1", "FE80::c000:0201", or 278 "192.0.2.1" and IPv6 syntax is preferred: 280 HOST 192.0.2.1 281 HOST [FE80::c000:0201] 282 HOST [::192.0.2.1] 284 The client MUST NOT send the port number as part of the HOST command, 285 even when the client has been instructed to connect to a non-standard 286 port. The reason for this requirement is that the user-PI will have 287 established a connection to the server-PI before the HOST command is 288 sent, therefore specifying a different port with the HOST command has 289 no meaning. For example, the server-PI MUST respond with a 501 reply 290 if the client sends a HOST command with syntax like either of the 291 following examples: 293 HOST 192.0.2.1:2112 294 HOST [FE80::c000:0201]:2112 296 The hostname parameter is otherwise to be treated as a fully 297 qualified domain name or relative name as those terms are defined in 298 section 3.1 of [RFC1034]. This implies that the name is to be 299 treated as a case-independent string, meaning that uppercase ASCII 300 characters are to be treated as equivalent to their corresponding 301 lowercase ASCII characters, but otherwise preserved as given. It 302 also implies some limits on the length of the parameter and of the 303 components that create its internal structure. Those limits are not 304 altered in any way here. 306 Neither [RFC1034] nor [RFC1035] impose any other restrictions upon 307 what kinds of names can be stored in the DNS. This specification, 308 however, only allows the use of names that can be inferred from the 309 ABNF grammar given for the "hostname". 311 3.2. HOST command semantics 313 Upon receiving the HOST command, before authenticating the user-PI, a 314 server-FTP process SHOULD validate that the hostname given represents 315 a valid virtual host for that server, and, if it is valid, establish 316 the appropriate environment for that virtual host. The resultant 317 actions needed to create that environment are not specified here, and 318 may range from doing nothing at all, to performing a simple change of 319 working directory, changing authentication schemes and/or username 320 and password lists, or making much more elaborate state changes - 321 such as creating isolated environments for each FTP session. 323 The "220" reply code for the HOST command is the same as the code 324 that is used in the initial "welcome" message that is sent after the 325 connection is established. 327 If the hostname specified would normally be acceptable, but for any 328 reason is temporarily unavailable, the server-FTP process SHOULD 329 reply to the HOST command with a 421 reply and close the connection. 330 In this particular situation, the server-FTP process MAY choose to 331 keep the connection open in order to allow the user-PI an opportunity 332 to choose another virtual host with a subsequent HOST command. 334 If the hostname specified is unknown at the server, or if the server 335 is otherwise unwilling to treat the particular connection as a 336 connection to the hostname specified, the server SHOULD respond with 337 a 504 reply. 339 3.2.1. REIN command semantics 341 As specified in [RFC0959], the REIN command returns the state of the 342 connection to what it was immediately after the transport connection 343 was opened. This specification makes no changes to that behavior. 344 The effect of a HOST command MUST be reset if a REIN command is 345 performed, and a new HOST command MUST be issued in order to connect 346 to a virtual host. 348 3.2.2. User-PI usage of HOST 350 A user-PI that conforms to this specification MUST send the HOST 351 command after opening the transport connection, or after any REIN 352 command, before attempting to authenticate the user with the USER 353 command. The following example illustrates what a typical login 354 sequence might look like when the HOST command is used: 356 C> HOST ftp.example.com 357 S> 220 Host accepted 358 C> USER foo 359 S> 331 Password required 360 C> PASS bar 361 S> 230 User logged in 363 If a user-PI sends an additional HOST command before attempting to 364 authenticate the user, a server-FTP process that conforms to this 365 specification MUST treat the additional HOST command as though a 366 previous HOST command was not sent, and return the appropriate reply 367 for the new HOST command. For example, if a user specifies the wrong 368 virtual host by mistake, sending a subsequent HOST command will 369 rectify the error. The following example illustrates what the login 370 sequence might look like when the HOST command is sent twice before a 371 user has been authenticated: 373 C> HOST foo.example.com 374 S> 220 Host accepted 375 C> HOST bar.example.com 376 S> 220 Host accepted 377 C> USER foo 378 S> 331 Password required 379 C> PASS bar 380 S> 230 User logged in 382 The HOST command can be used in combination with the ACCT command to 383 differentiate between a user's various accounts on a specific virtual 384 host. In this scenario, the user-PI sends a HOST command which the 385 server-PI uses to route activity to the correct virtual host; the 386 user-PI sends credentials using the USER and PASS commands which the 387 server-PI validates; then, the user-PI sends an ACCT command to 388 specify any additional account information for the server-PI 389 implementation. The following example illustrates a sequential 390 series of client commands that specify both a HOST and ACCT, with the 391 server responses omitted for brevity: 393 C> HOST ftp.example.com 394 C> USER foo 395 C> PASS bar 396 C> ACCT project1 398 This is also true when the HOST command is used with the AUTH and 399 ADAT commands that are discussed in [RFC2228] and [RFC4217]. In this 400 scenario, the user-PI sends a HOST command which the server-PI uses 401 to route activity to the correct virtual host, then the user-PI uses 402 the AUTH and ADAT commands to negotiate the security mechanism and 403 relevant authentication token(s) with the server-PI, then the user-PI 404 sends user credentials using the USER and PASS commands which the 405 server-PI validates. After which the user-PI MAY send an ACCT 406 command to specify any additional account information for the 407 server-PI implementation. The following example illustrates a 408 sequential series of client commands that specify both a HOST and 409 ACCT when used in conjunction with the security commands that are 410 discussed in [RFC2228] and [RFC4217], with the server responses 411 omitted for brevity: 413 C> HOST ftp.example.com 414 C> AUTH 415 C> ADAT 416 C> USER foo 417 C> PASS bar 418 C> ACCT project1 420 3.2.3. State Diagrams 422 The state diagrams in this section illustrate typical sequences for 423 command and reply interchange between the user-PI and server-PI. 424 These diagrams are modeled on the similar diagrams in section 6 of 425 [RFC0959]. 427 In each diagram, the (B) "begin" state is assumed to occur after the 428 transport connection has opened, or after a REIN command has 429 succeeded. Other commands (such as FEAT [RFC2389]) that require no 430 authentication may have intervened. 432 Additionally, a three-digit reply indicates a precise server reply 433 code. A single digit on a reply path indicates any server reply that 434 begins with that digit, except where a precise server reply code is 435 defined on another path. For example, a single digit "5" will apply 436 to "500", "501", "502", etc., when those reply codes are not 437 expressly defined in the diagram. For each command there are three 438 possible outcomes: success (S), failure (F), and error (E). In the 439 state diagrams below we use the symbol B for "begin", and the symbol 440 W for "wait for reply". 442 In each of these diagrams, a REIN command will return the diagram to 443 the (B) "begin" state. 445 The state diagram in Figure 1 shows a typical sequence of flow of 446 control when HOST is used with USER and PASS to log in to a 447 particular FTP virtual host. 449 +---+ HOST +---+ 1,3,5 450 | B |---------->| W |----------------- 451 +---+ +---+ | 452 | | | 453 2,500,502 | | 4,501,503,504 | 454 -------------- ----------- | 455 | | V 456 V 1 | +---+ 457 +---+ USER +---+-------------->| E | 458 | |---------->| W | 2 | +---+ 459 +---+ +---+------- | ^ 460 | | | | | 461 3 | | 4,5 | | | 462 -------------- ----- | | | 463 | | | | | 464 | ------------------- 465 | 1| | | | 466 V | | ------>+---+ 467 +---+ PASS +---+ 2 | | | S | 468 | |---------->| W |-------------->+---+ 469 +---+ +---+ | | 470 | | | 471 |4,5 | | 472 | | --->+---+ 473 | --------->| F | 474 ---------------->+---+ 476 Figure 1: Typical login sequence with HOST command 478 After a user has logged in, an additional account may be required by 479 the server and specified by the client by using ACCT command. With 480 this in mind, the state diagram in Figure 2 shows a typical sequence 481 of flow of control when HOST is used with USER and PASS to log in to 482 an FTP virtual host and ACCT is used to specify an account. 484 +---+ HOST +---+ 1,3,5 485 | B |---------->| W |----------------- 486 +---+ +---+ | 487 | | | 488 2,500,502 | | 4,501,503,504 | 489 -------------- ------------- | 490 | | | 491 V 1 | V 492 +---+ USER +---+-------------->+---+ 493 | |---------->| W | 2 ----->| E | 494 +---+ +---+------ | --->+---+ 495 | | | | | | 496 3 | | 4,5 | | | | 497 -------------- ----- | | | | 498 | | | | | | 499 | | | | | | 500 | ---------- | | 501 | 1| | | | | 502 V | | | | | 503 +---+ PASS +---+ 2 | ------->+---+ 504 | |---------->| W |-------------->| S | 505 +---+ +---+ ----------->+---+ 506 | | | | | | 507 3 | |4,5| | | | 508 -------------- -------- | ---- 509 | | | | | | 510 | | | | | | 511 | ------------ | 512 | 1,3| | | | | 513 V | 2| | | V 514 +---+ ACCT +---+-- | ------>+---+ 515 | |---------->| W | 4,5 --------->| F | 516 +---+ +---+-------------->+---+ 518 Figure 2: Login sequence with HOST and ACCT commands 520 When the HOST command is used in combination with the FTP security 521 extensions that were introduced in [RFC2228], it SHOULD precede the 522 security handshake. This allows both user-PI and server-FTP 523 processes to map an FTP HOST to security data appropriately. The 524 state diagram in Figure 3 shows a typical sequence of flow of control 525 when HOST is used with the AUTH and ADAT commands that are discussed 526 in [RFC2228]. 528 +---+ HOST +---+ 1,3,5 529 | B |---------->| W |------------------ 530 +---+ +---+ | 531 | | | 532 2,500,502 | | 4,501,503,504 | 533 -------------- ------------- | 534 | | | 535 V | | 536 +---+ AUTH +---+ 4,5 | | 537 | |---------->| W |----------->| | 538 +---+ +---+ | | 539 334 | | | | 540 -------------- | | | 541 | 234 | | | 542 | ------------ | | 543 V | 4,5 | | 544 +---+ | ADAT +---+----------->| | 545 | |---------->| W | 335 | | 546 +---+ | +---+----- | | 547 ^ | | | | | 548 | | | | | | 549 ----------------------- | | 550 | | | | 551 ---- 235 | | | 552 | -------------- | | 553 | | | V 554 V V 1 | +---+ 555 +---+ USER +---+--------------->| E | 556 | |---------->| W | 2 | +---+ 557 +---+ +---+------- | ^ 558 | | | | | 559 3 | | 4,5 | | | 560 -------------- ------ | | | 561 | | | | | 562 | -------------------- 563 | 1| | | | 564 V | | ------->+---+ 565 +---+ PASS +---+ 2 | | | S | 566 | |---------->| W |--------------->+---+ 567 +---+ +---+ | | 568 | | | 569 |4,5 | | 570 | | -->+---+ 571 | --------->| F | 572 ----------------->+---+ 574 Figure 3: Login sequence with HOST and AUTH/ADAT commands 576 After a user has logged in with the security commands that are 577 discussed in [RFC2228], an additional account may be required by the 578 server and specified by the client by using ACCT command. The state 579 diagram in Figure 4 shows a typical sequence of flow of control when 580 HOST is used with the AUTH and ADAT commands to log in to an FTP 581 virtual host and ACCT is used to specify an account. 583 +---+ HOST +---+ 1,3,5 584 | B |---------->| W |------------------ 585 +---+ +---+ | 586 | | | 587 2,500,502 | | 4,501,503,504 | 588 +-------------- -------------- | 589 | | | 590 V | | 591 +---+ AUTH +---+ 4,5 | | 592 | |---------->| W |------------>| | 593 +---+ +---+ | | 594 334 | | | | 595 -------------- | | | 596 | 234 | | | 597 | ------------ | | 598 V | 4,5 | | 599 +---+ | ADAT +---+------------>| | 600 | |---------->| W | 335 | | 601 +---+ | +---+----- | | 602 ^ | | | | | 603 | | | | | | 604 ----------------------- | | 605 | | | | 606 ---- 235| | | 607 | -------------- | | 608 | | | | 609 V V 1 | V 610 +---+ USER +---+--------------->+---+ 611 | |---------->| W | 2 ----->| E | 612 +---+ +---+------- | --->+---+ 613 | | | | | | 614 3 | | 4,5 | | | | 615 -------------- ------ | | | | 616 | | | | | | 617 | ----------- | | 618 | 1| | | | | 619 V | | | | | 620 +---+ PASS +---+ 2 | ------->+---+ 621 | |---------->| W |--------------->| S | 622 +---+ +---+ ------------>+---+ 623 | | | | | | 625 3 | |4,5| | | | 626 -------------- --------- | ---- 627 | | | | | | 628 | ------------- | 629 | 1,3| | | | | 630 V | 2| | | V 631 +---+ ACCT +---+-- | ------>+---+ 632 | |---------->| W | 4,5 --------->| F | 633 +---+ +---+--------------->+---+ 635 Figure 4: Login sequence with HOST and AUTH/ADAT/ACCT commands 637 3.3. HOST command errors 639 The server-PI SHOULD reply with a 500 or 502 reply if the HOST 640 command is unrecognized or unimplemented. 642 As discussed in section 3 of this document, if a HOST command is sent 643 after a user has been authenticated, the server MUST treat the 644 situation as an invalid sequence of commands and return a 503 reply. 646 A 501 reply SHOULD be sent if the hostname given is syntactically 647 invalid, and a 504 reply SHOULD be sent if a syntactically valid 648 hostname is not a valid virtual host name for the server. In all 649 such cases, the server-FTP process MUST do one of the following: 651 a. Ignore the HOST command and act as if a HOST command had not been 652 sent. A user-FTP process MAY then send a subsequent HOST command 653 with a different hostname. 655 b. Close the connection. 657 A user-PI receiving a 500 or 502 reply to a HOST command SHOULD 658 assume that the server-PI does not implement virtual servers by using 659 the HOST command. The user-PI MAY then proceed to login as if the 660 HOST command had not been sent. 662 A user-PI receiving an error reply that is different from the errors 663 that have been described here SHOULD assume that the virtual HOST is 664 unavailable, and terminate communications. 666 A server-PI that receives a USER command to begin the authentication 667 sequence without having received a HOST command SHOULD NOT reject the 668 USER command. Clients conforming to earlier FTP specifications do 669 not send HOST commands. In this case the server MAY act as if some 670 default virtual host had been explicitly selected, or MAY enter an 671 environment that is different from that of any supported virtual 672 hosts, perhaps one in which a union of all available accounts exists 673 and which presents an NVFS that appears to contain subdirectories 674 that contain the NVFS for all supported virtual hosts. 676 3.4. FEAT response for HOST command 678 When replying to the FEAT command [RFC2389], a server-FTP process 679 that supports the HOST command MUST include a line containing the 680 single word "HOST". This word is case insensitive, and MAY be sent 681 in any mixture of upper or lower case, however it SHOULD be sent in 682 upper case. That is, the response SHOULD be: 684 C> FEAT 685 S> 211- 686 S> ... 687 S> HOST 688 S> ... 689 S> 211 End 691 The ellipses indicate place holders where other features may be 692 included, and are not required. The one-space indentation of the 693 feature lines is mandatory [RFC2389]. 695 4. Security Considerations 697 As discussed in section 3 of this document, a server implementation 698 MUST treat an additional HOST command that was sent before a user has 699 been authenticated as though a previous HOST command was not sent. 700 In this situation, the server implementation MUST reset the 701 authentication environment, as that would allow for segregation 702 between the security environments for each virtual host on an FTP 703 server. The implementation details for security environments may 704 vary greatly based on the requirements of each server implementation 705 and operating system, and those details are outside the scope of the 706 protocol itself. For example, a virtual host "foo.example.com" on an 707 FTP server might use a specific username and password list, while the 708 virtual host "bar.example.com" on the same FTP server might use a 709 different username and password list. In such a scenario, resetting 710 the security environment is necessary for the virtual servers to 711 appear to behave independently from a client perspective, while the 712 actual server implementation details are irrelevant at the protocol 713 level. 715 Section 15.1.1 of [RFC4217] discusses the use of X.509 certificates 716 for server authentication. Taking the information from that document 717 into account, when securing FTP sessions with the security mechanisms 718 that are defined in [RFC4217], client implementations SHOULD verify 719 that the hostname they specify in the parameter for the HOST command 720 matches the identity that is specified in the server's X.509 721 certificate in order to prevent man-in-the-middle attacks. 723 A general discussion of issues related to the security of FTP can be 724 found in [RFC2577]. 726 5. IANA Considerations 728 IANA is requested to register the following FTP extension according 729 to the procedure established by [RFC5797]: 731 +------+---------+-------------+------+------+----------------------+ 732 | cmd | FEAT | description | type | conf | RFC#s/References and | 733 | | Code | | | | Notes | 734 +------+---------+-------------+------+------+----------------------+ 735 | HOST | HOST | Hostname | a | o | TBD | 736 +------+---------+-------------+------+------+----------------------+ 738 NOTE TO RFC EDITOR: Please update TBD in the above table with the 739 number of this document. 741 6. References 743 6.1. Normative References 745 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol 746 (FTP)", STD 9, RFC 959, October 1985. 748 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 749 STD 13, RFC 1034, November 1987. 751 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 752 Specification", STD 13, RFC 1035, November 1987. 754 [RFC1123] Braden, R., "Requirements for Internet Hosts -- 755 Application and Support", STD 3, RFC 1123, October 1989. 757 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 758 Requirement Levels", BCP 14, RFC 2119, March 1997. 760 [RFC2228] Horowitz, M. and S. Lunt, "FTP Security Extensions", 761 RFC 2228, October 1997. 763 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 764 the File Transfer Protocol", RFC 2389, August 1998. 766 [RFC2640] Curtin, W., "Internationalization of the File Transfer 767 Protocol", RFC 2640, July 1999. 769 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 770 for Internationalized Domain Names in Applications 771 (IDNA)", RFC 3492, March 2003. 773 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 774 October 2005. 776 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 777 Specifications: ABNF", RFC 5234, January 2008. 779 6.2. Informative References 781 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 782 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 784 [RFC2577] Allman, M. and S. Ostermann, "FTP Security 785 Considerations", RFC 2577, May 1999. 787 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 788 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 789 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 791 [RFC5797] Klensin, J. and A. Hoenes, "FTP Command and Extension 792 Registry", RFC 5797, March 2010. 794 Appendix A. Unworkable Alternatives 796 Due to the level of scope for adding a new command to FTP, a brief 797 discussion of suggested alternatives to a HOST command and their 798 respective limitations is warranted. The suggested alternatives that 799 are discussed in this appendix have been proposed in the past, but 800 each of these ideas was deemed insufficient for the reasons that are 801 listed within each section of the appendix. 803 A.1. Overloading the CWD command 805 One suggested method to emulate a form of virtual hosts would be for 806 the client to simply send a "CWD" command after connecting, using the 807 virtual host name as the argument to the CWD command. This would 808 allow the server-FTP process to implement the file stores of the 809 virtual hosts as sub-directories in its NVFS. This suggestion is 810 simple in concept, and most server-FTP implementations support this 811 without requiring any code changes. While this method is simple to 812 describe, and to implement, it suffers from several drawbacks: 814 a. The "CWD" command is available only after the user-PI has 815 authenticated itself to the server-FTP process. Thus, all 816 virtual hosts would be required to share a common authentication 817 scheme if they used this method. 819 b. To make the virtual host truly transparent, either the server-FTP 820 process needs to be modified to include information that shows 821 the special nature of this first CWD command (negating most of 822 the advantage of this scheme), or all users must see the same 823 identical NVFS view upon connecting (they must connect in the 824 same initial directory), or the NVFS must implement the full set 825 of virtual host directories at each possible initial directory 826 for any possible user. 828 c. Unless the server is specially modified, a user connecting this 829 way to a virtual host would be able to easily move to any other 830 virtual host supported at the same server-FTP process, exposing 831 the nature of the virtual host. 833 A.2. Overloading the ACCT command 835 Another suggested method would be to simply overload the "ACCT" for 836 FTP virtual hosts, but this proposal is unacceptable for several 837 reasons with regard to when the ACCT command is sent during the 838 request flow. Sections 5.4 and 6 of [RFC0959] document the request 839 flow for a login sequence as USER -> PASS -> ACCT. This flow of 840 commands may be acceptable when you are considering a single user 841 having multiple accounts on an FTP server, but fails to differentiate 842 between virtual hosts when you consider the following two issues: 844 a. The first problem with overloading the ACCT command is 845 certificate negotiation when using the FTP security extensions 846 that are documented in [RFC2228] and [RFC4217]. In order to 847 safeguard user credentials, security mechanism and certificate 848 negotiation must occur before login credentials are sent by the 849 client. The problem with using the ACCT command in this scenario 850 is that there is no way of ensuring that the certificate matches 851 the correct virtual host before the user credentials are sent. 853 b. The second problem with overloading the ACCT command is how user 854 credentials are implemented for FTP virtual hosts. FTP server 855 implementations may allow the use of custom user credentials on a 856 per-virtual-host basis. For example, in one particular 857 implementation the virtual host negotiation occurs, and then the 858 user credentials are looked up using the account mechanism that 859 is specific to that virtual host. So once again the virtual host 860 negotiation must take place before the user credentials are sent. 862 A.3. Overloading the USER command 864 An additional suggestion would be to overload well-known syntax 865 through the existing USER command, as illustrated in the following 866 example: 868 C> USER foo@example.com 869 S> 331 Password required 870 C> PASS bar 871 S> 230 User logged in 873 In this example, the user "foo" might be attempting to log on to the 874 virtual host "example.com" on an FTP server. This suggestion may 875 seem plausible at first, but introduces several implementation 876 problems. For example: 878 a. Some network environments already use the "username@hostname" 879 syntax for network credentials, where the "hostname" portion 880 refers to the location of the user's credentials within the 881 network hierarchy. Using the "foo@example.com" syntax it becomes 882 difficult to differentiate between the user "foo" logging into a 883 virtual host named "example.com" on an FTP server versus the user 884 "foo@example.com" logging into an FTP server with no specified 885 virtual host. 887 b. When using the FTP security extensions that are documented in 888 [RFC2228] and [RFC4217], security mechanism and certificate 889 negotiation must occur before login credentials are sent by the 890 client. More specifically, the AUTH/ADAT commands must be sent 891 before the USER command in order to safeguard user credentials. 892 If you overload the USER command, there is no way of ensuring 893 that the certificate matches the correct virtual host before the 894 user credentials are sent by the client. 896 A.4. Conclusion 898 The conclusion from the examination of the existing possibilities 899 seems to be that in order to obtain an adequate emulation of "real" 900 FTP servers, client and server modifications to support virtual hosts 901 are necessary. Therefore a new FTP command seems the most likely 902 solution to provide the required level of support. 904 Appendix B. Acknowledgements 906 Robert Elz and Paul Hethmon provided a detailed discussion of the 907 HOST command in their Internet draft titled "Extensions to FTP" as 908 part of their work with the FTPEXT Working Group at the IETF. Their 909 work formed the basis for much of this document, and their help has 910 been greatly appreciated. They would also like to credit Bernhard 911 Rosenkraenzer for having first suggested and described the HOST 912 command. 914 Several people have provided a wealth of constructive feedback about 915 earlier versions of this document that have helped to shape its 916 development; many of their suggestions have been incorporated, and 917 their contributions are gratefully acknowledged. There are far too 918 many to mention here, but authors of this document would like to 919 specifically thank Alexey Melnikov, Alfred Hoenes, John Klensin, Joe 920 Touch, Paul Ford-Hutchinson, Daniel Stenberg, Mykyta Yevstifeyev, and 921 Anthony Bryan for their assistance. In addition, Alec Rowell's help 922 in making sections of this document more readable was invaluable. 924 Authors' Addresses 926 Paul Hethmon 927 Hethmon Brothers 928 2305 Chukar Road 929 Knoxville, TN 37923 930 USA 932 Email: phethmon@hethmon.com 934 Robert McMurray 935 Microsoft Corporation 936 One Microsoft Way 937 Redmond, WA 98052 938 USA 940 Email: robmcm@microsoft.com