File Transfer Protocol HOST Command for Virtual Hosts
updates
- rfc-959 — File Transfer Protocol
Extracted elements (27)
Overloading the ACCT command was rejected because ACCT is sent after USER and PASS in the login sequence, meaning virtual host selection would occur after credentials are sent—too late to select the correct TLS certificate or per-virtual-host credential store.
Overloading USER with 'user@hostname' syntax was rejected because it conflicts with existing network credential conventions and, when TLS is used, AUTH/ADAT must precede USER—making it impossible to route to the correct virtual host certificate before credentials are sent.
The CWD command was rejected as a virtual host mechanism because it is available only after authentication (forcing shared auth across virtual hosts), and it does not provide isolation since users can navigate to other virtual host directories.
The HOST command is modeled on the HTTP/1.1 Host header (RFC 2616), which solved the same virtual hosting problem for HTTP. FTP required both client and server modifications since no existing command could be cleanly repurposed.
Internationalization of domain names is supported only through IDNA 'A-labels' (e.g., 'xn--e1afmkfd.com'). Non-ASCII domain names must be converted to A-label form before use in the HOST command.
The HOST command can be combined with AUTH/ADAT (RFC 2228, RFC 4217) and ACCT commands. When TLS is not used, HOST precedes AUTH; when TLS SNI is used, HOST may follow the AUTH TLS exchange but the server must verify the names match.
User-PI implementations created before the introduction of HOST will not support the new command. A user-PI receiving a 500 or 502 reply to HOST SHOULD assume the server does not implement virtual servers via HOST and MAY proceed to log in as if HOST had not been sent.
A server-PI SHOULD validate that the hostname given represents a valid virtual host upon receiving HOST. If the hostname is syntactically invalid, a 501 reply SHOULD be sent; if valid but not a known virtual host, a 504 reply SHOULD be sent.
A server-PI that receives a USER command without a prior HOST command SHOULD NOT reject the USER command, since clients conforming to earlier FTP specifications do not send HOST commands.
A user-PI MUST send the HOST command after opening the transport connection, or after any REIN command, before attempting to authenticate the user with the USER command.
If a HOST command is sent, it MUST be issued before the user is authenticated, so that authentication scheme and authorized users can be dependent on the virtual host chosen.
If the IPv4 or IPv6 literal address specified by the client does not match the literal address for the server, the server MUST respond with a 504 reply to indicate that the address is not valid.
Server-FTP processes MUST treat a HOST command sent after the user has been authenticated as an erroneous sequence of commands and return a 503 reply.
Server-FTP processes MUST treat multiple HOST commands sent before authentication as if only the last HOST command had been sent, returning the appropriate reply for the last command.
The client MUST NOT send the port number as part of the HOST command, even when connecting to a non-standard port. The server-PI MUST respond with a 501 reply if a port number is included.
The effect of a HOST command MUST be reset if a REIN command is performed, and a new HOST command MUST be issued afterwards in order to connect to a virtual host.
The hostname parameter SHOULD be the same hostname used to obtain the IP address for the FTP control connection, after converting abbreviations to fully qualified domain names but before resolving CNAME aliases to canonical names.
When replying to FEAT, a server-FTP process that supports the HOST command MUST include a line containing the single word 'HOST'. It SHOULD be sent in upper case to maximize interoperability.
The HOST command is a new FTP command that allows a user-PI to specify which virtual host it wishes to connect to on a server-FTP process handling multiple virtual hosts at a single IP address. It takes a single hostname parameter and returns a 220 reply on success.
IANA registered the HOST command in the FTP Command and Extension Registry (per RFC 5797) with FEAT code 'HOST', description 'Hostname', type 'a' (access control), and conformance 'o' (optional).
Client implementations SHOULD protect user credentials by using the FTP security extensions introduced in RFC 2228 and RFC 4217; references to RFC 2577 provide further general FTP security guidance.
The HOST command SHOULD precede the TLS security handshake when the user-PI is not providing the 'server_name' TLS SNI extension, so both peers can map the FTP HOST to the correct server certificate before establishing the secure session.
When a new HOST command is received before authentication, the server MUST reset the authentication environment to ensure segregation between security environments for each virtual host, preventing credential leakage across virtual hosts.
When securing FTP sessions with TLS per RFC 4217, client implementations SHOULD verify that the hostname in the HOST command parameter matches the identity in the server's X.509 certificate to prevent man-in-the-middle attacks.
When the user-PI provides the hostname in the TLS SNI 'server_name' extension, the server-PI MUST verify that the name in the HOST command matches the 'server_name' extension value to prevent routing mismatches.
The HOST command login state machine begins at (B) after connection or REIN. HOST transitions to wait (W); on 2xx/500/502 the flow proceeds to USER; on 4xx/501/503/504 it may go to error (E) or allow retry. USER then PASS transitions yield success (S), failure (F), or error (E). A REIN at any wait state returns to (B).
The HOST command has the syntax: 'HOST SP hostname CRLF', where hostname is either a domain name (sub-domain *('.' sub-domain)) or an IP-literal (IPv6 address in square brackets or IPv4 address). The success response is '220 [SP *TCHAR] CRLF'.