idnits 2.17.1 draft-hethmon-mcmurray-ftp-hosts-15.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 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 mention this, which it should. 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2010) is 5064 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 (==), 5 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 R. McMurray 5 Intended status: Standards Track Microsoft 6 Expires: December 20, 2010 June 2010 8 File Transfer Protocol HOST Command for Virtual Hosts 9 draft-hethmon-mcmurray-ftp-hosts-15 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress". 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on December 20, 2010. 44 Copyright 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. 56 Abstract 58 This document defines a new FTP command that provides a mechanism for 59 FTP clients and servers to identify individual virtual hosts on an 60 FTP server. 62 Table of Contents 64 1. Introduction.....................................................2 65 2. Document Conventions ...........................................3 66 2.1. Basic Tokens ...............................................3 67 2.2. Server Replies .............................................4 68 3. The HOST command ................................................4 69 3.1. Syntax of the HOST command ..................................5 70 3.2. HOST command semantics ......................................7 71 3.2.1. REIN command semantics ..................................8 72 3.2.2. User-PI usage of HOST ...................................8 73 3.2.3. State Diagrams ..........................................9 74 3.3. HOST command errors ........................................12 75 3.4. FEAT response for HOST command .............................13 76 4. Security Considerations ........................................14 77 5. IANA Considerations ............................................14 78 6. References .....................................................14 79 6.1 Normative References ........................................14 80 6.2 Informative References ......................................15 81 Appendix A: Unworkable Alternatives ...............................16 82 A.1. Overloading the CWD command ................................16 83 A.2. Overloading the ACCT command ...............................16 84 A.3. Overloading the USER command ...............................17 85 A.4. Conclusion .................................................18 86 Acknowledgments ...................................................18 87 Authors' Addresses ................................................18 89 1. Introduction 91 It is common on the Internet for many DNS names to resolve to a 92 single IP address. This practice has introduced the concept of a 93 "virtual host", where a host appears to exist as an independent 94 entity, but in reality shares its physical resources with one or 95 more similar hosts. 97 Such an arrangement presents some problems for FTP servers, as an FTP 98 server distinguishes incoming FTP connections by their IP addresses, 99 not their DNS names, because hosts are uniquely identified by their 100 address rather than name. That is, all DNS names that share an IP 101 address are handled by the same FTP server and share the same Network 102 Virtual File System (NVFS). 104 This means that different virtual hosts cannot offer different 105 virtual file systems to clients, nor can they offer different 106 authentication systems. Any scheme to overcome this issue needs to 107 indicate not only the destination IP address, but also the virtual 108 host name that is associated with the desired virtual FTP server. 109 Typical user-FTP processes currently use hostnames to perform 110 hostname to IP address resolution and then ignore hostnames for the 111 rest of the FTP session, therefore any mechanism to overcome this 112 issue would require modifications to the user-PI and server-PI. 114 It should be noted that this same problem existed for HTTP/1.0 as 115 defined in [RFC1945], and was resolved in HTTP/1.1 as defined in 116 [RFC2616] through the addition of the Host request header. The goal 117 of this document is to bring a similar level of feature parity to FTP 118 by introducing a new HOST command that allows user-FTP processes to 119 specify which virtual host to connect to for a server-FTP process 120 that is handling requests for mutiple virtual hosts on a single IP 121 address. 123 2. Document Conventions 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 127 this document are to be interpreted as described in [RFC2119]. 129 In examples, "C>" and "S>" indicate lines sent by the client and 130 server, respectively. 132 This document also uses notation defined in [RFC959] and [RFC1123]. 133 In particular, the terms "reply", "user", "NVFS", "NVT", "file", 134 "pathname", "FTP commands", "DTP", "user-FTP process", "user-PI", 135 "user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode", 136 "type", "control connection", "data connection", and "ASCII", are 137 all used here as defined there. 139 Syntax required is defined using the Augmented BNF defined in 140 [RFC5234]. Some general ABNF definitions are required throughout the 141 document; those will be defined later in this section. At first 142 reading, it may be wise to simply recall that these definitions 143 exist here, and skip to the next section. 145 2.1. Basic Tokens 147 This document imports the core definitions given in Appendix B of 148 [RFC5234]. There definitions will be found for basic ABNF elements 149 like ALPHA, DIGIT, SP, etc. To that, the following term is added 150 for use in this document. 152 TCHAR = VCHAR / SP / HTAB ; visible plus white space 154 The VCHAR (from [RFC5234]) and TCHAR rules give basic character 155 types from varying sub-sets of the ASCII character set for use in 156 various commands and responses. 158 Note that in ABNF, string literals are case insensitive. That 159 convention is preserved in this document, and implies that FTP 160 commands and parameters that are added by this specification have 161 values that can be represented in any case. That is, "HOST" is the 162 same as "host", "Host", "HoSt", etc., and "ftp.example.com" is the 163 same as "Ftp.Example.Com", "fTp.eXample.cOm", etc. 165 2.2. Server Replies 167 Section 4.2 of [RFC959] defines the format and meaning of replies 168 by the server-PI to FTP commands from the user-PI. Those reply 169 conventions are used here without change. 171 error-response = error-code SP *TCHAR CRLF 172 error-code = ("4" / "5") 2DIGIT 174 Implementers should note that the ABNF syntax (which was not used in 175 [RFC959]) used in this document, and other FTP related documents, 176 sometimes shows replies using the one line format. Unless otherwise 177 explicitly stated, that is not intended to imply that multi-line 178 responses are not permitted. Implementers should assume that, unless 179 stated to the contrary, any reply to any FTP command (including QUIT) 180 can be of the multi-line format described in [RFC959]. 182 Throughout this document, replies will be identified by the three 183 digit code that is their first element. Thus the term "500 reply" 184 means a reply from the server-PI using the three digit code "500". 186 3. The HOST command 188 A new command "HOST" is added to the FTP command set to allow the 189 server-FTP process to determine to which of possibly many virtual 190 hosts the client wishes to connect. This command SHOULD be issued 191 before the user is authenticated, allowing the authentication scheme, 192 and set of legal users, to be dependent upon the virtual host chosen. 193 Server-FTP processes SHOULD treat a situation where the HOST command 194 is issued after the user has been authenticated using one of the 195 following two behaviors: 197 a. Treat the late HOST command as an erroneous sequence of 198 commands and return a 503 reply. 200 b. Treat the late HOST command as though a REIN command was sent 201 before the HOST command and reset the user-PI to the state that 202 existed after the TCP connection was first established and before 203 the initial user authentication and then return the appropriate 204 reply for the HOST command. 206 Servers should note that the response to the HOST command is a 207 sensible time to send their "welcome" message. This allows the 208 message to be personalized for any virtual hosts that are supported, 209 and also allows the client to determine the supported languages, or 210 representations, for the message, and other messages, via the FEAT 211 response, and select an appropriate one via the LANG command. See 212 [RFC2640] for more information. 214 3.1. Syntax of the HOST command 216 The HOST command is defined as follows. 218 host-command = "HOST" SP hostname CRLF 219 hostname = domain / IP-literal 221 domain = sub-domain *("." sub-domain) 222 sub-domain = let-dig [ldh-str] 223 let-dig = ALPHA / DIGIT 224 ldh-str = *( ALPHA / DIGIT / "-" ) let-dig 226 IP-literal = ( "[" IPv6address "]" ) / IPv4address 228 IPv6address = 6( h16 ":" ) ls32 229 / "::" 5( h16 ":" ) ls32 230 / [ h16 ] "::" 4( h16 ":" ) ls32 231 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 232 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 233 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 234 / [ *4( h16 ":" ) h16 ] "::" ls32 235 / [ *5( h16 ":" ) h16 ] "::" h16 236 / [ *6( h16 ":" ) h16 ] "::" 238 ls32 = ( h16 ":" h16 ) / IPv4address 239 ; least-significant 32 bits of address 241 h16 = 1*4HEXDIG 242 ; 16 bits of address represented in hexadecimal 244 IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet 246 dec-octet = DIGIT ; 0-9 247 / %x31-39 DIGIT ; 10-99 248 / "1" 2DIGIT ; 100-199 249 / "2" %x30-34 DIGIT ; 200-249 250 / "25" %x30-35 ; 250-255 252 host-response = host-ok / error-response 253 host-ok = "220" [ SP *TCHAR ] CRLF 255 As with all FTP commands, the "HOST" command word is case 256 independent, and MAY be specified in any character case desired. 258 The "hostname" (given as a parameter) specifies the virtual host to 259 which access is desired. This SHOULD be the same host name that was 260 used to obtain the IP address to which the FTP control connection was 261 made, after any client conversions have been completed that convert 262 an abbreviated or local alias to a complete (fully qualified) domain 263 name, but before resolving a DNS alias (owner of a CNAME resource 264 record) to its canonical name. 266 Internationalization of domain names is only supported through the 267 use of Punycode as described in [RFC3492]. 269 If the user was given an IPv4 or IPv6 literal address, and 270 consequently was not required to derive the literal address from a 271 hostname, the client MAY send the HOST command with the IPv4 or 272 IPv6 literal address as specified to it. While it may seem 273 counter-intuitive to specify a literal address by using the HOST 274 command after the client has already connected to the server using 275 a literal address, this should be expected behavior because a 276 user-FTP process should not be required to differentiate between a 277 fully qualified domain name and an IPv4 or IPv6 network literal 278 address. That being said, if the IPv4 or IPv6 literal address 279 specified by the client does not match the literal address for the 280 server, the server MUST respond with a 504 reply to indicate that 281 the IPv4 or IPv6 literal address is not valid. 283 When the hostname parameter contains a literal address, square 284 brackets are expected to disambiguate IPv6 address syntax from port 285 numbers syntax. Therefore, if the literal address is an IPv6 286 address, the IPv6 address is required to be enclosed in square 287 brackets (after eliminating any syntax that might also - but is not 288 required to - be enclosed in brackets, and from which the server 289 deduced that a literal address had been specified.) For example, the 290 following examples MAY be sent if the client had been instructed to 291 respectively connect to "192.0.2.1", "FE80::c000:0201", or 292 "192.0.2.1" and IPv6 syntax is preferred: 294 HOST 192.0.2.1 295 HOST [FE80::c000:0201] 296 HOST [::192.0.2.1] 298 The client MUST NOT send the port number as part of the HOST command, 299 even when the client has been instructed to connect to a non-standard 300 port. The reason for this requirement is that the user-PI will have 301 established a connection to the server-PI before the HOST command is 302 sent, therefore specifying a different port with the HOST command has 303 no meaning. For example, the server-PI MUST respond with a 501 reply 304 if the client sends a HOST command with syntax like either of the 305 following examples: 307 HOST 192.0.2.1:2112 308 HOST [FE80::c000:0201]:2112 310 The hostname parameter is otherwise to be treated as a fully 311 qualified domain name or relative name as those terms are defined 312 in section 3.1 of [RFC1034]. This implies that the name is to be 313 treated as a case-independent string, meaning that uppercase ASCII 314 characters are to be treated as equivalent to their corresponding 315 lowercase ASCII characters, but otherwise preserved as given. It 316 also implies some limits on the length of the parameter and of the 317 components that create its internal structure. Those limits are not 318 altered in any way here. 320 Neither [RFC1034] nor [RFC1035] impose any other restrictions upon 321 what kinds of names can be stored in the DNS. This specification, 322 however, allows only the of names that can be inferred from the ABNF 323 grammar given for the "hostname". 325 3.2. HOST command semantics 327 Upon receiving the HOST command, before authenticating the user-PI, a 328 server-FTP process SHOULD validate that the hostname given represents 329 a valid virtual host for that server, and, if it is valid, establish 330 the appropriate environment for that virtual host. The resultant 331 actions needed to create that environment are not specified here, and 332 may range from doing nothing at all, to performing a simple change of 333 working directory, to changing authentication schemes and/or username 334 and password lists, to making much more elaborate state changes, as 335 necessary. 337 The "220" reply code for the HOST command is the same as the code 338 that is used in the initial "welcome" message that is sent after 339 the connection is established. This reply code is used deliberately 340 in order to allow the implementation of a front-end FTP server as a 341 wrapper, which simply waits for the HOST command, and then invokes a 342 server that is compliant with [RFC959] in the appropriate environment 343 for the particular hostname received. 345 If the hostname specified would normally be acceptable, but for any 346 reason is temporarily unavailable, the server-FTP process SHOULD 347 reply to the HOST command with a 421 reply and close the connection. 348 In this particular situation, the server-FTP process MAY choose to 349 keep the connection open in order to allow the user-PI an opportunity 350 to choose another virtual host with a subsequent HOST command. 352 If the hostname specified is unknown at the server, or if the server 353 is otherwise unwilling to treat the particular connection as a 354 connection to the hostname specified, the server SHOULD respond with 355 a 504 reply. 357 3.2.1. REIN command semantics 359 As specified in [RFC959], the REIN command returns the state of 360 the connection to what it was immediately after the transport 361 connection was opened. This specification makes no changes to that 362 behavior. The effect of a HOST command MUST be reset if a REIN 363 command is performed, and a new HOST command MUST be issued in order 364 to connect to a virtual host. 366 3.2.2. User-PI usage of HOST 368 A user-PI that conforms to this specification MUST send the HOST 369 command after opening the transport connection, or after any REIN 370 command, before attempting to authenticate the user with the USER 371 command. The following example illustrates what a typical login 372 sequence might look like when the HOST command is used: 374 C> HOST ftp.example.com 375 S> 220 Host accepted 376 C> USER foo 377 S> 331 Password required 378 C> PASS bar 379 S> 230 User logged in 381 The HOST command can be used in combination with the ACCT command 382 to differentiate between a user's various accounts on a specific 383 virtual host. In this scenario, the user-PI sends a HOST command 384 which the server-PI uses to route activity to the correct virtual 385 host; the user-PI sends credentials using the USER and PASS commands 386 which the server-PI validates; then, the user-PI sends an ACCT 387 command to specify any additional account information for the 388 server-PI implementation. The following example illustrates a 389 sequential series of client commands that specify both a HOST and 390 ACCT, with the server responses omitted for brevity: 392 C> HOST ftp.example.com 393 C> USER foo 394 C> PASS bar 395 C> ACCT project1 397 This is also true when the HOST command is used with the AUTH and 398 ADAT commands that are discussed in [RFC2228] and [RFC4217]. In 399 this scenario, the user-PI sends a HOST command which the server-PI 400 uses to route activity to the correct virtual host, then the user-PI 401 uses the AUTH and ADAT commands to negotiate the security mechanism 402 and certificate with the server-PI, then the user-PI sends user 403 credentials using the USER and PASS commands which the server-PI 404 validates. After which the user-PI MAY send an ACCT command to 405 specify any additional account information for the server-PI 406 implementation. The following example illustrates a sequential 407 series of client commands that specify both a HOST and ACCT when 408 used in conjunction with the security commands that are discussed 409 in [RFC2228] and [RFC4217], with the server responses omitted for 410 brevity: 412 C> HOST ftp.example.com 413 C> AUTH 414 C> ADAT 415 C> USER foo 416 C> PASS bar 417 C> ACCT project1 419 3.2.3. State Diagrams 421 The state diagrams in this section illustrate typical sequences for 422 command and reply interchange between the user-PI and server-PI. 423 These diagrams are modeled on the similar diagrams in section 6 of 424 [RFC959]. 426 In each diagram, the (B) "begin" state is assumed to occur after 427 the transport connection has opened, or after a REIN command has 428 succeeded. Other commands (such as FEAT [RFC2389]) that require no 429 authentication may have intervened. 431 Additionally, a three-digit reply indicates a precise server reply 432 code. A single digit on a reply path indicates any server reply that 433 begins with that digit, except where a precise server reply code is 434 defined on another path. For example, a single digit "5" will apply 435 to "500", "501", "502", etc., when those reply codes are not 436 expressly defined in the diagram. For each command there are three 437 possible outcomes: success (S), failure (F), and error (E). In the 438 state diagrams below we use the symbol B for "begin", and the 439 symbol W for "wait for reply". 441 In each of these diagrams, a REIN command will return the diagram to 442 the (B) "begin" state. 444 The state diagram in Figure 1 shows a typical sequence of flow of 445 control when HOST is used with USER and PASS to log in to a 446 particular FTP virtual host. 448 +---+ HOST +---+ 1,3,5 449 | B |---------->| W |----------------- 450 +---+ +---+ | 451 | | | 452 2,500,502 | | 4,501,503,504 | 453 -------------- ------------ | 454 | | | 455 V 1 | V 456 +---+ USER +---+-------------->+---+ 457 | |---------->| W | 2 | | E | 458 +---+ +---+------ ----->+---+ 459 | | | | | 460 3 | | 4,5 | | | 461 -------------- ----- | | | 462 | | | | | 463 | ---------- | 464 | 1| | | | 465 V | | ------->+---+ 466 +---+ PASS +---+ 2 | | | S | 467 | |---------->| W |-------------->+---+ 468 +---+ +---+ | | 469 | | | 470 |4,5 | | 471 | | -->+---+ 472 | --------->| F | 473 ---------------->+---+ 475 Figure 1: Typical login sequence with HOST command 477 The state diagram in Figure 2 shows the flow of control when a HOST 478 command is sent after a user has already successfully logged in to a 479 virtual host with USER and PASS. 481 ------------------------------ 482 | | 483 | | 484 V | 485 +---+ HOST +---+ 1,3,5 | 486 | B |---------->| W |----------------- | 487 +---+ +---+ | | 488 | | | | 489 2,500,502 | | 4,501,503,504 | | 490 -------------- ------------ | | 491 | | | | 492 V 1 | V | 493 +---+ USER +---+-------------->+---+ | 494 | |---------->| W | 2 | | E | | 495 +---+ +---+------ ----->+---+ | 496 | | | | | | 497 3 | | 4,5 | | | | 498 -------------- ----- | | | | 499 | | | | | | 500 | ---------- | | 501 | | | | | | 502 | 1| | | | | 503 V | | ------->+---+ HOST | 504 +---+ PASS +---+ 2 | | | S |-------- 505 | |---------->| W |-------------->+---+ 506 +---+ +---+ | | 507 | | | 508 |4,5 | | 509 | | | 510 | | -->+---+ 511 | --------->| F | 512 ---------------->+---+ 514 Figure 2: Login sequence with repeated HOST command 516 After a user has logged in, an additional account may be required by 517 the server and specified by the client by using ACCT command. With 518 this in mind, the state diagram in Figure 3 shows a typical sequence 519 of flow of control when HOST is used with USER and PASS to log in to 520 an FTP virtual host and ACCT is used to specify an account. 522 +---+ HOST +---+ 1,3,5 523 | B |---------->| W |----------------- 524 +---+ +---+ | 525 | | | 526 2,500,502 | | 4,501,503,504 | 527 -------------- ------------- | 528 | | | 529 V 1 | V 530 +---+ USER +---+-------------->+---+ 531 | |---------->| W | 2 ----->| E | 532 +---+ +---+------ | --->+---+ 533 | | | | | | 534 3 | | 4,5 | | | | 535 -------------- ----- | | | | 536 | | | | | | 537 | | | | | | 538 | ---------- | | 539 | 1| | | | | 540 V | | | | | 541 +---+ PASS +---+ 2 | ------->+---+ 542 | |---------->| W |-------------->| S | 543 +---+ +---+ ----------->+---+ 544 | | | | | | 545 3 | |4,5| | | | 546 -------------- -------- | ---- 547 | | | | | | 548 | | | | | | 549 | ------------ | 550 | 1,3| | | | | 551 V | 2| | | V 552 +---+ ACCT +---+-- | ------>+---+ 553 | |---------->| W | 4,5 --------->| F | 554 +---+ +---+-------------->+---+ 556 Figure 3: Login sequence with HOST and ACCT commands 558 When the HOST command is used in combination with the FTP security 559 extensions that were introduced in [RFC2228], it SHOULD precede 560 the security handshake. This allows both user-PI and server-FTP 561 processes to map an FTP HOST to security data appropriately. The 562 state diagram in Figure 4 shows a typical sequence of flow of control 563 when HOST is used with the AUTH and ADAT commands that are discussed 564 in [RFC2228]. 566 +---+ HOST +---+ 1,3,5 567 | B |---------->| W |------------------ 568 +---+ +---+ | 569 | | | 570 2,500,502 | | 4,501,503,504 | 571 +-------------- ------------- | 572 | | | 573 V | | 574 +---+ AUTH +---+ 4,5 | | 575 | |---------->| W |----------->| | 576 +---+ +---+ | | 577 234 | | | | 578 --------- | 334 | | 579 | | | | 580 ---------------|------- | | 581 | | | | | | 582 V | V 335 | | | 583 +---+ | ADAT +---+----- | | 584 | |---------->| W | 4,5 | | 585 +---+ | +---+----------->| | 586 | | | | 587 ---- 235| | | 588 | -------------- | | 589 | | | | 590 V V 1 | V 591 +---+ USER +---+--------------->+---+ 592 | |---------->| W | 2 | | E | 593 +---+ +---+------- ----->+---+ 594 | | | | | 595 3 | | 4,5 | | | 596 -------------- ------ | | | 597 | | | | | 598 | ----------- | 599 | 1| | | | 600 V | | ------->+---+ 601 +---+ PASS +---+ 2 | | | S | 602 | |---------->| W |--------------->+---+ 603 +---+ +---+ | | 604 | | | 605 |4,5 | | 606 | | -->+---+ 607 | --------->| F | 608 ---------------->+---+ 610 Figure 4: Login sequence with HOST and AUTH/ADAT commands 612 After a user has logged in with the security commands that are 613 discussed in [RFC2228], an additional account may be required by the 614 server and specified by the client by using ACCT command. The state 615 diagram in Figure 5 shows a typical sequence of flow of control 616 when HOST is used with the AUTH and ADAT commands to log in to 617 an FTP virtual host and ACCT is used to specify an account. 619 +---+ HOST +---+ 1,3,5 620 | B |---------->| W |------------------ 621 +---+ +---+ | 622 | | | 623 2,500,502 | | 4,501,503,504 | 624 +-------------- -------------- | 625 | | | 626 V | | 627 +---+ AUTH +---+ 4,5 | | 628 | |---------->| W |------------>| | 629 +---+ +---+ | | 630 234 | | | | 631 --------- | 334 | | 632 | | | | 633 ---------------|------- | | 634 | | | | | | 635 V | V 335 | | | 636 +---+ | ADAT +---+----- | | 637 | |---------->| W | 4,5 | | 638 +---+ | +---+------------>| | 639 | | | | 640 ---- 235| | | 641 | -------------- | | 642 | | | | 643 V V 1 | V 644 +---+ USER +---+--------------->+---+ 645 | |---------->| W | 2 ----->| E | 646 +---+ +---+------- | --->+---+ 647 | | | | | | 648 3 | | 4,5 | | | | 649 -------------- ------ | | | | 650 | | | | | | 651 | ----------- | | 652 | 1| | | | | 653 V | | | | | 654 +---+ PASS +---+ 2 | ------->+---+ 655 | |---------->| W |--------------->| S | 656 +---+ +---+ ------------>+---+ 657 | | | | | | 658 3 | |4,5| | | | 659 -------------- --------- | ---- 660 | | | | | | 661 | ------------- | 662 | 1,3| | | | | 663 V | 2| | | V 664 +---+ ACCT +---+-- | ------>+---+ 665 | |---------->| W | 4,5 --------->| F | 666 +---+ +---+--------------->+---+ 668 Figure 5: Login sequence with HOST and AUTH/ADAT/ACCT commands 670 3.3. HOST command errors 672 The server-PI SHOULD reply with a 500 or 502 reply if the HOST 673 command is unrecognized or unimplemented. 675 As discussed in section 3 of this document, if a HOST command is sent 676 after a user has been authenticated the server SHOULD do one of the 677 following: 679 a. Send a 503 reply for an invalid sequence of commands. 681 b. Treat the HOST command as though a REIN command was sent and 682 reset the user-PI to the state that existed after the previous 683 HOST command was sent and before the user had been authenticated, 684 and then return the appropriate reply for the HOST command. 686 A 501 reply SHOULD be sent if the hostname given is syntactically 687 invalid, and a 504 reply SHOULD be sent if a syntactically valid 688 hostname is not a valid virtual host name for the server. In all 689 such cases, the server-FTP process MUST do one of the following: 691 a. Ignore the HOST command and act as if as if a HOST command 692 had not been sent. A user-FTP process MAY then send a subsequent 693 HOST command with a different hostname. 695 b. Close the connection. 697 A user-PI receiving a 500 or 502 reply to a HOST command SHOULD 698 assume that the server-PI does not implement virtual servers by using 699 the HOST command. The user-PI MAY then proceed to login as if the 700 HOST command had not been sent. 702 A user-PI receiving an error reply that is different from the errors 703 that have been described here SHOULD assume that the virtual HOST is 704 unavailable, and terminate communications. 706 A server-PI that receives a USER command to begin the authentication 707 sequence without having received a HOST command SHOULD NOT reject the 708 USER command. Clients conforming to earlier FTP specifications do 709 not send HOST commands. In this case the server MAY act as if some 710 default virtual host had been explicitly selected, or MAY enter an 711 environment that is different from that of any supported virtual 712 hosts, perhaps one in which a union of all available accounts exists 713 and which presents an NVFS that appears to contain subdirectories 714 that contain the NVFS for all supported virtual hosts. 716 3.4. FEAT response for HOST command 718 When replying to the FEAT command [RFC2389], a server-FTP process 719 that supports the HOST command MUST include a line containing the 720 single word "HOST". This word is case insensitive, and MAY be sent 721 in any mixture of upper or lower case, however it SHOULD be sent in 722 upper case. That is, the response SHOULD be: 724 C> FEAT 725 S> 211- 726 S> ... 727 S> HOST 728 S> ... 729 S> 211 End 731 The ellipses indicate place holders where other features may be 732 included, and are not required. The one-space indentation of the 733 feature lines is mandatory [RFC2389]. 735 4. Security Considerations 737 With the introduction of virtual hosts to FTP, server implementers 738 will need to take some care to ensure that the integrity of 739 potentially sensitive information is maintained. For example, while 740 hostnames may generally be assumed to be publicly available DNS 741 names, this may not always be the situation. Some organizations may 742 use private hostnames, and that information SHOULD be protected when 743 transmitted between the client and server by using a strong method of 744 encryption. 746 Server implementations SHOULD reset the security environment when a 747 HOST command is sent after a user has logged in. This allows for 748 individual authentication environments for each virtual host on an 749 FTP server. For example, a virtual host "foo.example.com" on an FTP 750 server might use a specific username and password list, while the 751 virtual host "bar.example.com" on the same FTP server might use a 752 different username and password list. In such a scenario, resetting 753 the security environment is necessary for virtual servers to appear 754 to behave independently. 756 A general discussion of issues related to the security of FTP can be 757 found in [RFC2577]. 759 5. IANA Considerations 761 IANA is requested to register the following FTP extension according 762 to the procedure established by [RFC5797]: 764 +-------+------+-------------------+------+------+------------------+ 765 | cmd | FEAT | description | type | conf | RFC#s/References | 766 | | Code | | | | and Notes | 767 +-------+------+-------------------+------+------+------------------+ 768 | HOST | HOST | Hostname | a | o | [#1] | 769 +-------+------+-------------------+------+------+------------------+ 771 [[ RFC Editor: Please update note #1 in the above table with the 772 number of this document. ]] 774 6. References 776 6.1. Normative References 778 [RFC959] Postel, J., Reynolds, J., "File Transfer Protocol (FTP)", 779 STD 9, RFC 959, October 1985 781 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 782 STD 13, RFC 1034, November 1987 784 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 785 Specification", STD 13, RFC 1035, November 1987 787 [RFC1123] Braden, R,. "Requirements for Internet Hosts -- 788 Application and Support", STD 3, RFC 1123, October 1989 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, March 1997 793 [RFC2228] Horowitz, M., Lunt, S., "FTP Security Extensions", 794 RFC 2228, October 1997 796 [RFC2389] Hethmon, P., Elz, R., "Feature negotiation mechanism for 797 the File Transfer Protocol", RFC 2389, August 1998 799 [RFC2640] Curtin, W., "Internationalization of the File Transfer 800 Protocol", RFC 2640, July 1999 802 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 803 for Internationalized Domain Names in Applications (IDNA)", 804 RFC 3492, March 2003 806 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 807 October 2005 809 [RFC5234] Crocker, D., Overell, P., "Augmented BNF for Syntax 810 Specifications: ABNF", RFC 5234, January 2008 812 6.2. Informative References 814 [RFC1945] Berners-Lee, T., Fielding, R., Frystyk, H., "Hypertext 815 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996 817 [RFC2577] Allman, M., Ostermann, S., "FTP Security Considerations", 818 RFC 2577, May 1999 820 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 821 Masinter, L., Leach, P., Berners-Lee, T., "Hypertext 822 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999 824 [RFC5797] Klensin, J., Hoenes, A., "FTP Command and Extension 825 Registry", March 2010 827 Appendix A: Unworkable Alternatives 829 Due to the level of scope for adding a new command to FTP, a brief 830 discussion of suggested alternatives to a HOST command and their 831 respective limitations is warranted. The suggested alternatives that 832 are discussed in this appendix have been proposed in the past, but 833 each of these ideas was deemed insufficient for the reasons that are 834 listed within each section of the appendix. 836 A.1. Overloading the CWD command 838 One suggested method to emulate a form of virtual hosts would be for 839 the client to simply send a "CWD" command after connecting, using the 840 virtual host name as the argument to the CWD command. This would 841 allow the server-FTP process to implement the file stores of the 842 virtual hosts as sub-directories in its NVFS. This suggestion is 843 simple in concept, and most server-FTP implementations support this 844 without requiring any code changes. While this method is simple to 845 describe, and to implement, it suffers from several drawbacks: 847 a. The "CWD" command is available only after the user-PI has 848 authenticated itself to the server-FTP process. Thus, all virtual 849 hosts would be required to share a common authentication scheme 850 if they used this method. 852 b. To make the virtual host truly transparent, either the 853 server-FTP process needs to be modified to include information 854 that shows the special nature of this first CWD command (negating 855 most of the advantage of this scheme), or all users must see the 856 same identical NVFS view upon connecting (they must connect in the 857 same initial directory), or the NVFS must implement the full set 858 of virtual host directories at each possible initial directory 859 for any possible user. 861 c. Unless the server is specially modified, a user connecting this 862 way to a virtual host would be able to easily move to any other 863 virtual host supported at the same server-FTP process, exposing 864 the nature of the virtual host. 866 A.2. Overloading the ACCT command 867 Another suggested method would be to simply overload the "ACCT" for 868 FTP virtual hosts, but this proposal is unacceptable for several 869 reasons with regard to when the ACCT command is sent during the 870 request flow. Sections 5.4 and 6 of [RFC959] document the request 871 flow for a login sequence as USER -> PASS -> ACCT. This flow of 872 commands may be acceptable when you are considering a single user 873 having multiple accounts on an FTP server, but fails to 874 differentiate between virtual hosts when you consider the following 875 two issues: 877 a. The first problem with overloading the ACCT command is 878 certificate negotiation when using the FTP security extensions 879 that are documented in [RFC2228] and [RFC4217]. In order to 880 safeguard user credentials, security mechanism and certificate 881 negotiation must occur before login credentials are sent by the 882 client. The problem with using the ACCT command in this scenario 883 is that there is no way of ensuring that the certificate matches 884 the correct virtual host before the user credentials are sent. 886 b. The second problem with overloading the ACCT command is how 887 user credentials are implemented for FTP virtual hosts. FTP 888 server implementations may allow the use of custom user 889 credentials on a per-virtual-host basis. For example, in one 890 particular implementation the virtual host negotiation occurs, 891 and then the user credentials are looked up using the account 892 mechanism that is specific to that virtual host. So once again 893 the virtual host negotiation must take place before the user 894 credentials are sent. 896 A.3. Overloading the USER command 898 An additional suggestion would be to overload well-known syntax 899 through the existing USER command, as illustrated in the following 900 example: 902 C> USER foo@example.com 903 S> 331 Password required 904 C> PASS bar 905 S> 230 User logged in 907 In this example, the user "foo" might be attempting to log on to the 908 virtual host "example.com" on an FTP server. This suggestion may 909 seem plausible at first, but introduces several implementation 910 problems. For example: 912 a. Some network environments already use the "username@hostname" 913 syntax for network credentials, where the "hostname" portion 914 refers to the location of the user's credentials within the 915 network hierarchy. Using the "foo@example.com" syntax it becomes 916 difficult to differentiate between the user "foo" logging into a 917 virtual host named "example.com" on an FTP server versus the user 918 "foo@example.com" logging into an FTP server with no specified 919 virtual host. 921 b. When using the FTP security extensions that are documented in 922 [RFC2228] and [RFC4217], security mechanism and certificate 923 negotiation must occur before login credentials are sent by the 924 client. More specifically, the AUTH/ADAT commands must be sent 925 before the USER command in order to safeguard user credentials. 926 If you overload the USER command, there is no way of ensuring that 927 the certificate matches the correct virtual host before the user 928 credentials are sent by the client. 930 A.4. Conclusion 932 The conclusion from the examination of the existing possibilities 933 seems to be that in order to obtain an adequate emulation of "real" 934 FTP servers, client and server modifications to support virtual hosts 935 are necessary. Therefore a new FTP command seems the most likely 936 solution to provide the required level of support. 938 Acknowledgments 940 Robert Elz and Paul Hethmon provided a detailed discussion of the 941 HOST command in their Internet draft titled "Extensions to FTP" 942 as part of their work with the FTPEXT Working Group at the IETF. 943 Their work formed the basis for much of this document, and their 944 help has been greatly appreciated. They would also like to credit 945 Bernhard Rosenkraenzer for having first suggested and described the 946 HOST command. 948 Alexey Melnikov, Alfred Hoenes, John Klensin, and Joe Touch have made 949 several suggestions about earlier versions of this document; many of 950 their suggestions have been incorporated, and their contributions are 951 gratefully acknowledged. In addition, Alec Rowell's assitance in 952 making sections of this document more readable was invaluable. 954 Authors' Addresses 956 Paul Hethmon 957 Hethmon Brothers 958 2305 Chukar Road 959 Knoxville, TN 37923 USA 961 Email: phethmon@hethmon.com 963 Robert McMurray 964 Microsoft Corporation 965 One Microsoft Way 966 Redmond, WA 98052-6399 967 Email: robmcm@microsoft.com