[要約] RFC 7151は、仮想ホストのためのファイル転送プロトコルのHOSTコマンドに関する仕様です。このRFCの目的は、仮想ホストをサポートするために、ファイル転送プロトコルに新しいコマンドを導入することです。
Internet Engineering Task Force (IETF) P. Hethmon
Request for Comments: 7151 Hethmon Brothers
Updates: 959 R. McMurray
Category: Standards Track Microsoft Corporation
ISSN: 2070-1721 March 2014
File Transfer Protocol HOST Command for Virtual Hosts
仮想ホスト用のファイル転送プロトコルHOSTコマンド
Abstract
概要
The File Transfer Protocol, as defined in RFC 959, does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server.
RFC 959で定義されているファイル転送プロトコルは、FTPクライアントとサーバーが単一のIPアドレスに登録されている複数のDNS名を区別する方法を提供していません。このドキュメントでは、FTPクライアントとサーバーがFTPサーバー上の個々の仮想ホストを識別するメカニズムを提供する新しいFTPコマンドを定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7151.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7151で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Document Conventions ............................................3
2.1. Basic Tokens ...............................................3
2.2. Server Replies .............................................4
3. The HOST Command ................................................4
3.1. Syntax of the HOST Command .................................5
3.2. HOST Command Semantics .....................................7
3.2.1. REIN Command Semantics ..............................8
3.2.2. User-PI Usage of HOST ...............................9
3.2.3. State Diagrams .....................................11
3.3. HOST Command Errors .......................................16
3.4. FEAT Response for HOST Command ............................17
4. Security Considerations ........................................17
5. IANA Considerations ............................................19
6. References .....................................................19
6.1. Normative References ......................................19
6.2. Informative References ....................................20
Appendix A. Unworkable Alternatives ...............................21
A.1. Overloading the CWD Command ................................21
A.2. Overloading the ACCT Command ...............................21
A.3. Overloading the USER Command ...............................22
A.4. Conclusion .................................................23
Appendix B. Acknowledgements ......................................23
It is common on the Internet for many DNS names to resolve to a single IP address. This practice has introduced the concept of a "virtual host", where a host appears to exist as an independent entity but, in reality, shares its physical resources with one or more similar hosts.
多くのDNS名が単一のIPアドレスに解決されることは、インターネットでは一般的です。この手法により、「仮想ホスト」の概念が導入されました。ホストは独立したエンティティとして存在しているように見えますが、実際には、1つ以上の同様のホストと物理リソースを共有しています。
Such an arrangement presents some problems for FTP servers, because an FTP server distinguishes incoming FTP connections by IP addresses rather than DNS names. Therefore, all DNS names that share a common IP address are handled by the same FTP server and share the same Network Virtual File System (NVFS).
FTPサーバーはDNS名ではなくIPアドレスで着信FTP接続を区別するため、このような配置にはFTPサーバーにいくつかの問題があります。したがって、共通のIPアドレスを共有するすべてのDNS名は、同じFTPサーバーによって処理され、同じネットワーク仮想ファイルシステム（NVFS）を共有します。
This means that different virtual hosts cannot offer different virtual file systems to clients, nor can they offer different authentication systems. Any scheme to overcome this issue needs to indicate not only the destination IP address but also the virtual hostname that is associated with the desired virtual FTP server. Typical user-FTP processes currently use hostnames to perform hostname-to-IP-address resolution and then ignore hostnames for the rest of the FTP session; therefore, any mechanism to overcome this issue would require modifications to the user protocol interpreter (user-PI) and server protocol interpreter (server-PI).
つまり、異なる仮想ホストがクライアントに異なる仮想ファイルシステムを提供したり、異なる認証システムを提供したりすることはできません。この問題を克服するためのスキームでは、宛先IPアドレスだけでなく、目的の仮想FTPサーバーに関連付けられている仮想ホスト名も示す必要があります。一般的なユーザーFTPプロセスは現在、ホスト名を使用してホスト名からIPアドレスへの解決を実行し、FTPセッションの残りの部分ではホスト名を無視します。したがって、この問題を解決するメカニズムでは、ユーザープロトコルインタープリター（ユーザーPI）とサーバープロトコルインタープリター（サーバーPI）の変更が必要になります。
It should be noted that this same problem existed for HTTP/1.0 as defined in [RFC1945] and was resolved in HTTP/1.1 as defined in [RFC2616] through the addition of the Host request header field. The goal of this document is to bring a similar level of feature parity to FTP by introducing a new HOST command that allows user-FTP processes to specify which virtual host to connect to for a server-FTP process that is handling requests for multiple virtual hosts on a single IP address.
これと同じ問題が[RFC1945]で定義されたHTTP / 1.0にも存在し、[RFC2616]で定義されたHTTP / 1.1でHostリクエストヘッダーフィールドの追加により解決されたことに注意してください。このドキュメントの目的は、ユーザーFTPプロセスが、複数の仮想ホストの要求を処理しているサーバーFTPプロセスに接続する仮想ホストを指定できる新しいHOSTコマンドを導入することにより、FTPに同様のレベルの機能パリティをもたらすことです。単一のIPアドレス。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
In examples, "C>" and "S>" indicate lines sent by the client and server, respectively.
例では、「C>」と「S>」は、それぞれクライアントとサーバーによって送信された行を示します。
This document also uses notation defined in [RFC959] and [RFC1123]. In particular, the terms "reply", "user", "NVFS", "NVT", "file", "pathname", "FTP commands", "DTP", "user-FTP process", "user-PI", "user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode", "type", "control connection", "data connection", and "ASCII", are all used here as defined there.
このドキュメントでは、[RFC959]と[RFC1123]で定義されている表記法も使用しています。特に、「返信」、「ユーザー」、「NVFS」、「NVT」、「ファイル」、「パス名」、「FTPコマンド」、「DTP」、「ユーザーFTPプロセス」、「ユーザーPI」という用語、「user-DTP」、「server-FTP process」、「server-PI」、「server-DTP」、「mode」、「type」、「control connection」、「data connection」、および「ASCII」は、ここで定義されているすべてがここで使用されます。
The required syntax is defined using the Augmented BNF defined in [RFC5234]. Some general ABNF definitions are required throughout the document; they will be defined in subsequent sections.
必要な構文は、[RFC5234]で定義されているAugmented BNFを使用して定義されています。ドキュメント全体でいくつかの一般的なABNF定義が必要です。それらは後続のセクションで定義されます。
With the increased use of virtualization technologies, there may be several possible definitions for the term "virtual host". This document follows the definition from Section 4.1.14 of [RFC3875], where several virtual hosts share the same IP address, and hostnames are used by the server-FTP process to route user-PI sessions to the appropriate virtual host.
仮想化テクノロジーの使用が増えるにつれ、「仮想ホスト」という用語にはいくつかの定義が存在する可能性があります。このドキュメントは、[RFC3875]のセクション4.1.14の定義に従います。ここでは、複数の仮想ホストが同じIPアドレスを共有し、サーバーのFTPプロセスでホスト名を使用して、ユーザーのPIセッションを適切な仮想ホストにルーティングします。
This document imports the core definitions given in Appendix B of [RFC5234]. There, definitions will be found for basic ABNF elements like ALPHA, DIGIT, SP, etc. To that, the following term is added for use in this document.
このドキュメントでは、[RFC5234]の付録Bに記載されている主要な定義をインポートします。そこでは、ALPHA、DIGIT、SPなどの基本的なABNF要素の定義が見つかります。それに加えて、このドキュメントで使用するために次の用語が追加されています。
TCHAR = VCHAR / SP / HTAB ; visible plus white space
The VCHAR (from [RFC5234]) and TCHAR rules give basic character types from varying subsets of the ASCII character set for use in various commands and responses.
VCHAR（[RFC5234]から）およびTCHARルールは、さまざまなコマンドおよび応答で使用するために、ASCII文字セットのさまざまなサブセットからの基本的な文字タイプを提供します。
Note that in ABNF, string literals are case insensitive. That convention is preserved in this document and implies that FTP commands and parameters that are added by this specification have values that can be represented in any case. That is, "HOST" is the same as "host", "Host", "HoSt", etc. Similarly, because domain names are defined to be case insensitive, "ftp.example.com" is the same as "Ftp.Example.Com", "fTp.eXample.cOm", etc.
ABNFでは、文字列リテラルは大文字と小文字を区別しないことに注意してください。この規則はこのドキュメントで保持されており、この仕様によって追加されたFTPコマンドおよびパラメーターには、どのような場合でも表現できる値があることを意味します。つまり、「HOST」は「host」、「Host」、「HoSt」などと同じです。同様に、ドメイン名は大文字と小文字を区別しないように定義されているため、「ftp.example.com」は「Ftp。」と同じです。 Example.Com "、" fTp.eXample.cOm "など
Section 4.2 of [RFC959] defines the format and meaning of replies by the server-PI to FTP commands from the user-PI. Those reply conventions are used here without change.
[RFC959]のセクション4.2は、ユーザーPIからFTPコマンドへのサーバーPIによる応答の形式と意味を定義しています。ここでは、これらの返信規則をそのまま使用します。
error-response = error-code SP *TCHAR CRLF
error-code = ("4" / "5") 2DIGIT
Implementers should note that the ABNF syntax used in this document and other FTP-related documents (but that was not used in [RFC959]) sometimes shows replies using the one-line format. Unless otherwise explicitly stated, multi-line responses are also permitted. Implementers should assume that, unless stated to the contrary, any reply to any FTP command (including QUIT) can be of the multi-line format described in [RFC959].
実装者は、このドキュメントおよび他のFTP関連のドキュメントで使用されたABNF構文（ただし[RFC959]では使用されなかった）は、1行形式を使用して返信を表示する場合があることに注意する必要があります。特に明記されていない限り、複数行の応答も許可されます。実装者は、反対に述べられていない限り、FTPコマンド（QUITを含む）への応答は、[RFC959]で説明されている複数行形式である可能性があると想定する必要があります。
Throughout this document, replies will be identified by the three-digit code that is their first element. Thus, the term "500 reply" means a reply from the server-PI using the three-digit code "500".
このドキュメント全体で、返信は最初の要素である3桁のコードで識別されます。したがって、「500応答」という用語は、3桁のコード「500」を使用したサーバーPIからの応答を意味します。
A new command, "HOST", is added to the FTP command set in order to allow a server-FTP process to determine to which of possibly many virtual hosts the client wishes to connect. If a HOST command is sent, it MUST be issued before the user is authenticated, as this will allow the authentication scheme and set of authorized users to be dependent upon the virtual host that is chosen.
新しいコマンド「HOST」がFTPコマンドセットに追加され、サーバーFTPプロセスが、クライアントが接続する可能性のある多くの仮想ホストのどれに接続するかを決定できるようにします。 HOSTコマンドを送信する場合、ユーザーが認証される前に発行する必要があります。これにより、認証スキームと許可されたユーザーのセットが、選択された仮想ホストに依存するようになるためです。
Server-FTP processes MUST treat a situation in which the HOST command is issued more than once before the user has been authenticated as though only the last HOST command had been sent, and return the appropriate reply for the last HOST command. Server-FTP processes MUST treat a situation in which the HOST command is issued after the user has been authenticated as an erroneous sequence of commands and return a 503 reply.
サーバーFTPプロセスは、ユーザーが認証される前にHOSTコマンドが複数回発行された状況を、最後のHOSTコマンドのみが送信されたかのように扱い、最後のHOSTコマンドに対する適切な応答を返さなければなりません（MUST）。サーバーFTPプロセスは、ユーザーが認証された後にHOSTコマンドが発行された状況を、誤ったコマンドシーケンスとして扱い、503応答を返す必要があります。
Servers should note that the response to the HOST command is a sensible time to send their "welcome" message. This allows the message to be personalized for any virtual hosts that are supported. It also allows the client to determine, via the FEAT response, the languages or representations supported by the server and select an appropriate one via the LANG command. See [RFC2640] for more information.
サーバーは、HOSTコマンドへの応答が「ウェルカム」メッセージを送信するのに適切な時間であることに注意する必要があります。これにより、サポートされているすべての仮想ホストに対してメッセージをパーソナライズできます。また、クライアントは、FEAT応答を介して、サーバーがサポートする言語または表現を決定し、LANGコマンドを使用して適切なものを選択できます。詳細については、[RFC2640]を参照してください。
It should be noted that user-PI implementations that were created before the introduction of the HOST command will not support this new command. A similar problem existed with the introduction of the Host header for HTTP in [RFC2616], and HTTP server implementations had to determine how best to accommodate HTTP requests from down-level clients that did not support the Host header. With this in mind, server-FTP processes will need to determine how best to accommodate FTP requests from down-level FTP clients that do not support the HOST command, but those considerations are outside the scope of this document.
HOSTコマンドが導入される前に作成されたユーザーPI実装は、この新しいコマンドをサポートしないことに注意してください。 [RFC2616]でのHTTPのホストヘッダーの導入にも同様の問題があり、HTTPサーバーの実装では、ホストヘッダーをサポートしていない下位レベルのクライアントからのHTTPリクエストに対応する最善の方法を決定する必要がありました。これを念頭に置いて、サーバーFTPプロセスは、HOSTコマンドをサポートしない下位レベルのFTPクライアントからのFTP要求に対応する最善の方法を決定する必要がありますが、これらの考慮事項はこのドキュメントの範囲外です。
The HOST command is defined as follows. Note that [RFC3986] remains the normative specification for the syntactic form of IPv4 and IPv6 address literals, in order to ensure identical presentation in 'ftp' URI hostname parts and in the protocol element specified here.
HOSTコマンドは次のように定義されています。 [RFC3986]は、IPv4およびIPv6アドレスリテラルの構文形式の規範的な仕様であり、 'ftp' URIホスト名部分とここで指定されたプロトコル要素で同じ表示を保証するために注意してください。
host-command = "HOST" SP hostname CRLF hostname = domain / IP-literal
host-command = "HOST" SP hostname CRLF hostname = domain / IP-literal
domain = sub-domain *("." sub-domain)
sub-domain = let-dig [ldh-str]
let-dig = ALPHA / DIGIT
ldh-str = *( ALPHA / DIGIT / "-" ) let-dig
IP-literal = ( "[" IPv6address "]" ) / IPv4address
IPv6address = <see [RFC3986] Section 3.2.2>
IPv4address = <see [RFC3986] Section 3.2.2>
host-response = host-ok / error-response
host-ok = "220" [ SP *TCHAR ] CRLF
The "hostname" rule is a restricted form of the "host" rule specified in [RFC3986]. Details of the additional restrictions imposed by this document are given in the discussion of the syntax that occurs later in this section; they aim at simplifying implementations by only allowing what currently is specified precisely and in use on the Internet.
「ホスト名」ルールは、[RFC3986]で指定された「ホスト」ルールの制限された形式です。このドキュメントによって課される追加の制限の詳細は、このセクションの後半で発生する構文の説明に記載されています。彼らは、現在正確に指定され、インターネットで使用されているものだけを許可することで、実装の簡素化を目指しています。
As with all FTP commands, the "HOST" command word is case independent and can be specified in any character case desired.
すべてのFTPコマンドと同様に、「HOST」コマンドワードは大文字と小文字を区別せず、任意の大文字と小文字を使用して指定できます。
The "hostname" (given as a parameter) specifies the virtual host to which access is desired. This SHOULD be the same hostname that was used to obtain the IP address to which the FTP control connection was made, after any client conversions have been completed that convert an abbreviated or local alias to a complete (fully qualified) domain name, but before resolving a DNS alias (owner of a CNAME resource record) to its canonical name.
「パラメーター」として与えられる「ホスト名」は、アクセスが望まれる仮想ホストを指定します。これは、省略またはローカルエイリアスを完全な（完全修飾）ドメイン名に変換するクライアント変換が完了した後、解決する前に、FTP制御接続が行われたIPアドレスを取得するために使用されたのと同じホスト名である必要があります正規名へのDNSエイリアス（CNAMEリソースレコードの所有者）。
Internationalization of domain names is only supported through the use of Internationalized Domain Names for Applications (IDNA) "A-labels" for <sub-domain> as described in [RFC5890]. For example, the following HOST command specifies an internationalized domain name:
ドメイン名の国際化は、[RFC5890]で説明されているように、<sub-domain>の国際化アプリケーション名（IDNA） "A-labels"の使用を通じてのみサポートされます。たとえば、次のHOSTコマンドは国際化ドメイン名を指定しています。
HOST xn--e1afmkfd.com
ホストxn--e1afmkfd.com
If the user was given an IPv4 or IPv6 literal address, and consequently was not required to derive the literal address from a hostname, the client MAY send the HOST command with the IPv4 or IPv6 literal address as specified to it. While it may seem counterintuitive to specify a literal address by using the HOST command after the client has already connected to the server using a literal address, this should be expected behavior because a user-FTP process should not be required to differentiate between a fully qualified domain name and an IPv4 or IPv6 network literal address. That being said, 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 IPv4 or IPv6 literal address is not valid.
ユーザーにIPv4またはIPv6リテラルアドレスが与えられたため、ホスト名からリテラルアドレスを取得する必要がなかった場合、クライアントは指定されたIPv4またはIPv6リテラルアドレスを使用してHOSTコマンドを送信できます（MAY）。クライアントがリテラルアドレスを使用してサーバーに接続した後でHOSTコマンドを使用してリテラルアドレスを指定するのは直観に反するように見えるかもしれませんが、完全修飾を区別するためにユーザーFTPプロセスを必要としないため、これは予想される動作です。ドメイン名とIPv4またはIPv6ネットワークリテラルアドレス。つまり、クライアントによって指定されたIPv4またはIPv6リテラルアドレスがサーバーのリテラルアドレスと一致しない場合、サーバーは504応答で応答して、IPv4またはIPv6リテラルアドレスが無効であることを示す必要があります。
When the hostname parameter contains a literal address, square brackets are expected to disambiguate IPv6 address syntax from port numbers syntax. Therefore, if the literal address is an IPv6 address, the IPv6 address is required to be enclosed in square brackets (after eliminating any syntax that might also -- but is not required to -- be enclosed in brackets, and from which the server deduced that a literal address had been specified). For example, the following examples MAY be sent if the client had been instructed to connect to "192.0.2.1", "2001:db8::c000:201", or "::192.0.2.1", respectively, and IPv6 syntax is preferred:
ホスト名パラメーターにリテラルアドレスが含まれている場合、角かっこでIPv6アドレスの構文とポート番号の構文を明確にすることが期待されます。したがって、リテラルアドレスがIPv6アドレスである場合、IPv6アドレスは角かっこで囲む必要があります（角かっこで囲まれている可能性がありますが、必須ではない構文を削除した後、サーバーから推定されます）リテラルアドレスが指定されていたこと）。たとえば、クライアントが「192.0.2.1」、「2001：db8 :: c000：201」、または「:: 192.0.2.1」にそれぞれ接続するように指示されていて、IPv6構文が次の場合、次の例が送信される場合があります。推奨：
HOST 192.0.2.1
HOST [2001:db8::c000:201]
HOST [::192.0.2.1]
The client MUST NOT send the port number as part of the HOST command, even when the client has been instructed to connect to a non-standard port. The reason for this requirement is that the user-PI will have established a connection to the server-PI before the HOST command is sent; therefore, specifying a different port with the HOST command has no meaning. For example, the server-PI MUST respond with a 501 reply if the client sends a HOST command with syntax like either of the following examples:
クライアントが非標準ポートに接続するように指示されている場合でも、クライアントはHOSTコマンドの一部としてポート番号を送信してはなりません（MUST NOT）。この要件の理由は、HOSTコマンドが送信される前に、ユーザーPIがサーバーPIへの接続を確立しているためです。したがって、HOSTコマンドで別のポートを指定しても意味がありません。たとえば、クライアントが次のいずれかの例のような構文でHOSTコマンドを送信した場合、サーバーPIは501応答で応答する必要があります。
HOST 192.0.2.1:2112
HOST [2001:db8::c000:201]:2112
The hostname parameter is otherwise to be treated as a fully qualified domain name or relative name as those terms are defined in Section 3.1 of [RFC1034]. This implies that the name is to be treated as a case-independent string, meaning that uppercase ASCII characters are to be treated as equivalent to their corresponding lowercase ASCII characters but otherwise preserved as given. It also implies some limits on the length of the parameter and of the components that create its internal structure. Those limits are not altered in any way here.
それ以外の場合、ホスト名パラメータは[RFC1034]のセクション3.1で定義されているように、完全修飾ドメイン名または相対名として扱われます。これは、名前が大文字と小文字を区別しない文字列として扱われることを意味します。つまり、大文字のASCII文字は対応する小文字のASCII文字と同等として扱われますが、それ以外は指定どおりに保持されます。また、パラメータとその内部構造を作成するコンポーネントの長さにいくつかの制限があることも意味します。これらの制限は、ここでは決して変更されません。
Neither [RFC1034] nor [RFC1035] imposes any other restrictions upon what kinds of names can be stored in the DNS. This specification, however, only allows the use of names that can be inferred from the ABNF grammar given for the "hostname". Similarly, this specification restricts address literals to the IPv4 and IPv6 address families well established on the Internet.
[RFC1034]も[RFC1035]も、DNSに格納できる名前の種類に他の制限を課しません。ただし、この仕様では、「ホスト名」に指定されたABNF文法から推測できる名前のみを使用できます。同様に、この仕様は、アドレスリテラルをインターネット上で確立されたIPv4およびIPv6アドレスファミリに制限しています。
Upon receiving the HOST command, before authenticating the user-PI, a server-FTP process SHOULD validate that the hostname given represents a valid virtual host for that server and, if it is valid, establish the appropriate environment for that virtual host. The resultant actions needed to create that environment are not specified here and may range from doing nothing at all to performing a simple change of working directory, changing authentication schemes and/or username and password lists, or making much more elaborate state changes -- such as creating isolated environments for each FTP session.
HOSTコマンドを受信すると、ユーザーPIを認証する前に、サーバーFTPプロセスは、指定されたホスト名がそのサーバーの有効な仮想ホストを表していることを検証し、有効であれば、その仮想ホストに適切な環境を確立します。その環境を作成するために必要な結果のアクションはここでは指定されていません。何もしないことから、作業ディレクトリの単純な変更の実行、認証スキームやユーザー名とパスワードのリストの変更、またははるかに複雑な状態の変更など、多岐にわたります。 FTPセッションごとに分離された環境を作成する。
The 220 reply code for the HOST command is the same as the code that is used in the initial "welcome" message that is sent after the connection is established.
HOSTコマンドの220応答コードは、接続が確立された後に送信される最初の「ウェルカム」メッセージで使用されるコードと同じです。
If the hostname specified would normally be acceptable, but is temporarily unavailable, the server-FTP process SHOULD respond to the HOST command with a 421 reply and close the connection.
指定されたホスト名は通常は受け入れられるが、一時的に利用できない場合、サーバーFTPプロセスはHOSTコマンドに421応答で応答し、接続を閉じる必要があります（SHOULD）。
Example:
例：
The server-FTP process is shutting down, so the server-FTP process responds to the HOST command with a 421 reply and closes the connection. In this scenario, the 421 reply informs the client it can retry at another time.
サーバーFTPプロセスがシャットダウンしているため、サーバーFTPプロセスはHOSTコマンドに421応答で応答し、接続を閉じます。このシナリオでは、421応答はクライアントに別の時間に再試行できることを通知します。
If the hostname specified is unknown at the server, or if the server is otherwise unwilling to treat the particular connection as a connection to the hostname specified, the server SHOULD respond with a 504 reply.
指定されたホスト名がサーバーで不明である場合、またはサーバーが特定の接続を指定されたホスト名への接続として扱いたくない場合、サーバーは504応答で応答する必要があります（SHOULD）。
Examples:
例：
The particular virtual host that was specified by the HOST command is disabled at the server. The server responds with a 504 reply and keeps the connection open in order to allow the user-PI an opportunity to specify another virtual host with a subsequent HOST command.
HOSTコマンドで指定された特定の仮想ホストは、サーバーで無効になっています。サーバーは504応答で応答し、ユーザーPIが後続のHOSTコマンドで別の仮想ホストを指定できるようにするために、接続を開いたままにします。
Alternatively, the server-FTP process might choose to route all connections with unknown hostnames to a different virtual host so that no connection attempts will result in failed connections. This design would be implementation specific and outside the scope of this specification.
または、サーバーFTPプロセスは、不明なホスト名を持つすべての接続を別の仮想ホストにルーティングすることを選択する場合があります。これにより、接続の試行によって接続が失敗することはありません。この設計は実装固有であり、この仕様の範囲外です。
As specified in [RFC959], the REIN command returns the state of the connection to what it was immediately after the transport connection was opened. This specification makes no changes to that behavior. 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.
[RFC959]で指定されているように、REINコマンドは、トランスポート接続が開かれた直後の状態に接続の状態を返します。この仕様はその動作に変更を加えません。 REINコマンドが実行された場合は、HOSTコマンドの効果をリセットする必要があり、仮想ホストに接続するために、後で新しいHOSTコマンドを発行する必要があります。
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. The following example illustrates what a typical login sequence might look like when the HOST command is used:
user-PIは、トランスポート接続を開いた後、またはREINコマンドの後、USERコマンドでユーザーを認証する前に、HOSTコマンドを送信する必要があります。次の例は、HOSTコマンドを使用した場合の典型的なログインシーケンスを示しています。
C> HOST ftp.example.com S> 220 Host accepted C> USER foo S> 331 Password required C> PASS bar S> 230 User logged in
C>ホストftp.example.com S> 220ホスト承認済みC>ユーザーfoo S> 331パスワードが必要C>パスバーS> 230ユーザーがログイン
If a user-PI sends an additional HOST command before attempting to authenticate the user, a server-FTP process MUST treat the additional HOST command as though a previous HOST command was not sent and return the appropriate reply for the new HOST command. For example, if a user specifies the wrong virtual hostname by mistake, sending a subsequent HOST command will rectify the error. The following example illustrates what the login sequence might look like when the HOST command is sent twice before a user has been authenticated:
ユーザーPIがユーザーの認証を試みる前に追加のHOSTコマンドを送信する場合、サーバーFTPプロセスは、追加のHOSTコマンドを、以前のHOSTコマンドが送信されなかったかのように扱い、新しいHOSTコマンドに対する適切な応答を返す必要があります。たとえば、ユーザーが間違った仮想ホスト名を誤って指定した場合、後続のHOSTコマンドを送信するとエラーが修正されます。次の例は、ユーザーが認証される前にHOSTコマンドが2回送信された場合のログインシーケンスを示しています。
C> HOST foo.example.com S> 220 Host accepted C> HOST bar.example.com S> 220 Host accepted C> USER foo S> 331 Password required C> PASS bar S> 230 User logged in
C> HOST foo.example.com S> 220ホスト承認済みC> HOST bar.example.com S> 220ホスト承認済みC> USER foo S> 331パスワードが必要C> PASSバーS> 230ユーザーがログイン
The HOST command can be used in combination with the ACCT command to differentiate between a user's various accounts on a specific virtual host. In this scenario, the user-PI sends a HOST command, which the server-PI uses to route activity to the correct virtual host; the user-PI sends credentials using the USER and PASS commands, which the server-PI validates; then, the user-PI sends an ACCT command to specify any additional account information for the server-PI implementation. The following example illustrates a sequential series of client commands that specify both a HOST and ACCT, with the server responses omitted for brevity:
HOSTコマンドをACCTコマンドと組み合わせて使用すると、特定の仮想ホスト上のユーザーのさまざまなアカウントを区別できます。このシナリオでは、ユーザーPIがHOSTコマンドを送信します。サーバーコマンドは、このコマンドを使用して、アクティビティを正しい仮想ホストにルーティングします。ユーザーPIは、サーバーPIが検証するUSERコマンドとPASSコマンドを使用して資格情報を送信します。次に、ユーザーPIはACCTコマンドを送信して、サーバーPI実装の追加のアカウント情報を指定します。次の例は、HOSTとACCTの両方を指定する一連の一連のクライアントコマンドを示しています。簡潔にするためにサーバーの応答は省略しています。
C> HOST ftp.example.com C> USER foo C> PASS bar C> ACCT project1
C>ホストftp.example.com C>ユーザーfoo C>パスバーC> ACCTプロジェクト1
This is also true when the HOST command is used with the AUTH and ADAT commands that are discussed in [RFC2228] and [RFC4217]. In this scenario, the user-PI sends a HOST command, which the server-PI uses to route activity to the correct virtual host; then, the user-PI uses the AUTH and ADAT commands to negotiate the security mechanism and relevant authentication token(s) with the server-PI; then, the user-PI sends user credentials using the USER and PASS commands, which the server-PI validates, after which the user-PI MAY send an ACCT command to specify any additional account information for the server-PI implementation. The following example illustrates a sequential series of client commands that specify both HOST and ACCT commands when used in conjunction with the security commands that are discussed in [RFC2228] and [RFC4217], with the server responses omitted for brevity:
これは、[RFC2228]および[RFC4217]で説明されているAUTHおよびADATコマンドとともにHOSTコマンドを使用する場合にも当てはまります。このシナリオでは、ユーザーPIがHOSTコマンドを送信します。サーバーコマンドは、このコマンドを使用して、アクティビティを正しい仮想ホストにルーティングします。次に、ユーザーPIはAUTHコマンドとADATコマンドを使用して、サーバーPIとセキュリティメカニズムと関連する認証トークンをネゴシエートします。次に、ユーザーPIは、サーバーPIが検証するUSERコマンドとPASSコマンドを使用してユーザー資格情報を送信します。その後、ユーザーPIがACCTコマンドを送信して、サーバーPI実装の追加のアカウント情報を指定できます（MAY）。次の例は、[RFC2228]と[RFC4217]で説明されているセキュリティコマンドと組み合わせて使用するときにHOSTコマンドとACCTコマンドの両方を指定する一連の一連のクライアントコマンドを示しています。
C> HOST ftp.example.com
C> AUTH <mechanism-name>
C> ADAT <base64data>
C> USER foo
C> PASS bar
C> ACCT project1
An exception to the above scenario would be when a user-PI is providing the hostname in the "server_name" extension of a Transport Layer Security (TLS) extended client hello as discussed in [RFC6066]. When the user-PI specifies the hostname in the "server_name" extension of a TLS extended client hello, the server-PI MUST verify that the hostname in the HOST command matches the value of the "server_name" extension. The following example illustrates a sequential series of client commands that specify the HOST command when used in conjunction with the TLS extensions that are discussed in [RFC6066], with the server responses omitted for brevity:
上記のシナリオの例外は、[RFC6066]で説明されているように、ユーザーPIがトランスポート層セキュリティ（TLS）拡張クライアントhelloの「server_name」拡張でホスト名を提供している場合です。 user-PIがTLS拡張クライアントhelloの「server_name」拡張でホスト名を指定する場合、server-PIはHOSTコマンドのホスト名が「server_name」拡張の値と一致することを確認する必要があります。次の例は、[RFC6066]で説明されているTLS拡張と組み合わせて使用する場合にHOSTコマンドを指定する一連のクライアントコマンドを示しています。簡潔にするためにサーバーの応答は省略しています。
C> AUTH TLS C> HOST ftp.example.com C> USER foo C> PASS bar
C> AUTH TLS C>ホストftp.example.com C>ユーザーfoo C>パスバー
Additional security information about using the HOST command with the security extensions that are discussed in [RFC2228], [RFC4217], and [RFC6066] is provided in Section 4 of this document.
[RFC2228]、[RFC4217]、および[RFC6066]で説明されているセキュリティ拡張機能でのHOSTコマンドの使用に関する追加のセキュリティ情報は、このドキュメントのセクション4で提供されています。
The state diagrams in this section illustrate typical sequences for command and reply interchange between the user-PI and server-PI. These diagrams are modeled on the similar diagrams in Section 6 of [RFC959].
このセクションの状態図は、ユーザーPIとサーバーPIの間のコマンドと応答の交換の一般的なシーケンスを示しています。これらの図は、[RFC959]のセクション6の同様の図に基づいてモデル化されています。
In each diagram, the (B) "begin" state is assumed to occur after the transport connection has opened or after a REIN command has succeeded. Other commands (such as FEAT [RFC2389]) that require no authentication may have intervened.
各図で、（B）「開始」状態は、トランスポート接続が開いた後、またはREINコマンドが成功した後に発生すると想定されています。認証を必要としない他のコマンド（FEAT [RFC2389]など）が介入した可能性があります。
Additionally, a three-digit reply indicates a precise server reply code. A single digit on a reply path indicates any server reply that begins with that digit, except where a precise server reply code is defined on another path. For example, a single digit "5" will apply to "500", "501", "502", etc., when those reply codes are not expressly defined in the diagram. For each command, there are three possible outcomes: success (S), failure (F), or error (E). In the state diagrams below, we use the symbol "B" for "begin" and the symbol "W" for "wait for reply".
さらに、3桁の応答は正確なサーバー応答コードを示します。応答パス上の1つの数字は、正確なサーバー応答コードが別のパスで定義されている場合を除き、その数字で始まるサーバー応答を示します。たとえば、これらの応答コードが図で明確に定義されていない場合、1桁の「5」は「500」、「501」、「502」などに適用されます。コマンドごとに、成功（S）、失敗（F）、またはエラー（E）の3つの結果が考えられます。以下の状態図では、「開始」には記号「B」を使用し、「応答を待機」には記号「W」を使用しています。
For each of these diagrams, without any state transitions being shown, a REIN command will return the diagram from any wait state to the (B) "begin" state.
これらの図のそれぞれについて、状態遷移が表示されていない場合、REINコマンドは図を待機状態から（B）「開始」状態に戻します。
The state diagram in Figure 1 shows a typical sequence of flow of control when HOST is used with USER and PASS to log in to a particular FTP virtual host.
図1の状態図は、特定のFTP仮想ホストにログインするためにHOSTをUSERおよびPASSとともに使用する場合の制御の典型的なフローシーケンスを示しています。
+---+ HOST +---+ 1,3,5
| B |---------->| W |-----------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
-------------- ----------- |
| | V
V 1 | +---+
+---+ USER +---+-------------->| E |
| |---------->| W | 2 | +---+
+---+ +---+------- | ^
| | | | |
3 | | 4,5 | | |
-------------- ----- | | |
| | | | |
| -------------------
| 1| | | |
V | | ------>+---+
+---+ PASS +---+ 2 | | | S |
| |---------->| W |-------------->+---+
+---+ +---+ | |
| | |
|4,5 | |
| | --->+---+
| --------->| F |
---------------->+---+
Figure 1: Typical Login Sequence with HOST Command
図1：HOSTコマンドを使用した一般的なログインシーケンス
After a user has logged in, an additional account may be required by the server and specified by the client by using the ACCT command. With this in mind, the state diagram in Figure 2 shows a typical sequence of flow of control when HOST is used with USER and PASS to log in to an FTP virtual host and ACCT is used to specify an account.
ユーザーがログインした後、サーバーが追加のアカウントを要求し、ACCTコマンドを使用してクライアントが指定する場合があります。これを念頭に置いて、図2の状態図は、HOSTをUSERおよびPASSと共に使用してFTP仮想ホストにログインし、ACCTを使用してアカウントを指定する場合の制御の典型的なフローを示しています。
+---+ HOST +---+ 1,3,5
| B |---------->| W |-----------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
-------------- ------------- |
| | |
V 1 | V
+---+ USER +---+-------------->+---+
| |---------->| W | 2 ----->| E |
+---+ +---+------ | --->+---+
| | | | | |
3 | | 4,5 | | | |
-------------- ----- | | | |
| | | | | |
| | | | | |
| ---------- | |
| 1| | | | |
V | | | | |
+---+ PASS +---+ 2 | ------->+---+
| |---------->| W |-------------->| S |
+---+ +---+ ----------->+---+
| | | | | |
3 | |4,5| | | |
-------------- -------- | ----
| | | | | |
| | | | | |
| ------------ |
| 1,3| | | | |
V | 2| | | V
+---+ ACCT +---+-- | ------>+---+
| |---------->| W | 4,5 --------->| F |
+---+ +---+-------------->+---+
Figure 2: Login Sequence with HOST and ACCT Commands
図2：HOSTおよびACCTコマンドを使用したログインシーケンス
The state diagram in Figure 3 shows a typical sequence of flow of control when HOST is used with the AUTH and ADAT commands that are discussed in [RFC2228]. (NOTE: Section 4 provides additional information about using the HOST command with TLS.)
図3の状態図は、[RFC2228]で説明されているAUTHおよびADATコマンドでHOSTが使用されている場合の制御の流れの典型的なシーケンスを示しています。 （注：セクション4では、TLSでのHOSTコマンドの使用に関する追加情報を提供します。）
+---+ HOST +---+ 1,3,5
| B |---------->| W |------------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
-------------- ------------- |
| | |
V | |
+---+ AUTH +---+ 4,5 | |
| |---------->| W |----------->| |
+---+ +---+ | |
334 | | | |
-------------- | | |
| 234 | | |
| ------------ | |
V | 4,5 | |
+---+ | ADAT +---+----------->| |
| |---------->| W | 335 | |
+---+ | +---+----- | |
^ | | | | |
| | | | | |
----------------------- | |
| | | |
---- 235 | | |
| -------------- | |
| | | V
V V 1 | +---+
+---+ USER +---+--------------->| E |
| |---------->| W | 2 | +---+
+---+ +---+------- | ^
| | | | |
3 | | 4,5 | | |
-------------- ------ | | |
| | | | |
| --------------------
| 1| | | |
V | | ------->+---+
+---+ PASS +---+ 2 | | | S |
| |---------->| W |--------------->+---+
+---+ +---+ | |
| | |
|4,5 | |
| | -->+---+
| --------->| F |
----------------->+---+
Figure 3: Login Sequence with HOST and AUTH/ADAT Commands
図3：HOSTおよびAUTH / ADATコマンドを使用したログインシーケンス
After a user has logged in with the security commands that are discussed in [RFC2228], an additional account may be required by the server and specified by the client by using the ACCT command. The state diagram in Figure 4 shows a typical sequence of flow of control when HOST is used with the AUTH and ADAT commands to log in to an FTP virtual host and ACCT is used to specify an account.
[RFC2228]で説明されているセキュリティコマンドを使用してユーザーがログインした後、サーバーが追加のアカウントを要求し、ACCTコマンドを使用してクライアントが指定する場合があります。図4の状態図は、AUTHコマンドとADATコマンドでHOSTを使用してFTP仮想ホストにログインし、ACCTを使用してアカウントを指定した場合の典型的な制御の流れを示しています。
+---+ HOST +---+ 1,3,5
| B |---------->| W |------------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
+-------------- -------------- |
| | |
V | |
+---+ AUTH +---+ 4,5 | |
| |---------->| W |------------>| |
+---+ +---+ | |
334 | | | |
-------------- | | |
| 234 | | |
| ------------ | |
V | 4,5 | |
+---+ | ADAT +---+------------>| |
| |---------->| W | 335 | |
+---+ | +---+----- | |
^ | | | | |
| | | | | |
----------------------- | |
| | | |
---- 235| | |
| -------------- | |
| | | |
V V 1 | V
+---+ USER +---+--------------->+---+
| |---------->| W | 2 ----->| E |
+---+ +---+------- | --->+---+
| | | | | |
3 | | 4,5 | | | |
-------------- ------ | | | |
| | | | | |
| ----------- | |
| 1| | | | |
V | | | | |
+---+ PASS +---+ 2 | ------->+---+
| |---------->| W |--------------->| S |
+---+ +---+ ------------>+---+
| | | | | |
3 | |4,5| | | |
-------------- --------- | ----
| | | | | |
| ------------- |
| 1,3| | | | |
V | 2| | | V
+---+ ACCT +---+-- | ------>+---+
| |---------->| W | 4,5 --------->| F |
+---+ +---+--------------->+---+
Figure 4: Login Sequence with HOST and AUTH/ADAT/ACCT Commands
The server-PI SHOULD return a 500 or 502 reply if the HOST command is unrecognized or unimplemented, as specified in [RFC959]. For example, a server-PI that predates or otherwise does not conform to this specification would be expected to return a 500 or 502 reply.
[RFC959]で指定されているように、HOSTコマンドが認識されないか実装されていない場合、サーバーPIは500または502の応答を返す必要があります（SHOULD）。たとえば、この仕様に先行するか、この仕様に準拠していないサーバーPIは、500または502の応答を返すことが期待されます。
As discussed in Section 3 of this document, if a HOST command is sent after a user has been authenticated, the server MUST treat the situation as an invalid sequence of commands and return a 503 reply.
このドキュメントのセクション3で説明したように、ユーザーが認証された後にHOSTコマンドが送信された場合、サーバーはその状況を無効なコマンドシーケンスとして扱い、503応答を返す必要があります。
A 501 reply SHOULD be sent if the hostname given is syntactically invalid, and a 504 reply SHOULD be sent if a syntactically valid hostname is not a valid virtual hostname for the server. In all such cases, the server-FTP process MUST do one of the following:
指定されたホスト名が構文的に無効な場合は、501応答を送信する必要があります（SHOULD）。構文的に有効なホスト名がサーバーの有効な仮想ホスト名でない場合は、504応答を送信する必要があります（SHOULD）。このような場合はすべて、サーバーFTPプロセスで次のいずれかを実行する必要があります。
a. Ignore the HOST command and act as if a HOST command had not been sent. A user-FTP process MAY then send a subsequent HOST command with a different hostname.
a. HOSTコマンドを無視し、HOSTコマンドが送信されなかったかのように動作します。その後、ユーザーFTPプロセスは、別のホスト名で後続のHOSTコマンドを送信する場合があります。
b. Close the connection.
b. 接続を閉じます。
A user-PI receiving a 500 or 502 reply to a HOST command SHOULD assume that the server-PI does not implement virtual servers by using the HOST command. The user-PI MAY then proceed to log in as if the HOST command had not been sent.
HOSTコマンドへの500または502応答を受信するユーザーPIは、サーバーPIがHOSTコマンドを使用して仮想サーバーを実装していないと想定する必要があります（SHOULD）。その後、ユーザーPIは、HOSTコマンドが送信されなかったかのようにログインに進むことができます（MAY）。
A user-PI receiving an error reply that is different from the errors that have been described here SHOULD assume that the virtual HOST is unavailable and terminate communications.
ここで説明されているエラーとは異なるエラー応答を受け取るユーザーPIは、仮想ホストが使用不可であると想定して、通信を終了する必要があります。
A server-PI that receives a USER command to begin the authentication sequence without having received a HOST command SHOULD NOT reject the USER command. Clients that conform to earlier FTP specifications do not send HOST commands. In this case, the server MAY act as if some default virtual host had been explicitly selected, or the server MAY enter an environment that is different from that of any supported virtual hosts, perhaps one in which a union of all available accounts exists and that presents an NVFS that appears to contain subdirectories that contain the NVFS for all supported virtual hosts.
HOSTコマンドを受信せずにUSERコマンドを受信して認証シーケンスを開始するサーバーPIは、USERコマンドを拒否する必要があります（SHOULD NOT）。以前のFTP仕様に準拠するクライアントは、HOSTコマンドを送信しません。この場合、サーバーは、デフォルトの仮想ホストが明示的に選択されているかのように動作する可能性があります。または、サーバーは、サポートされている仮想ホストとは異なる環境に入る可能性があります。サポートされているすべての仮想ホストのNVFSを含むサブディレクトリが含まれているように見えるNVFSを示します。
When replying to the FEAT command [RFC2389], a server-FTP process that supports the HOST command MUST include a line containing the single word "HOST". This word is case insensitive, but it SHOULD be sent in upper case so as to maximize interoperability with disparate implementations. That is, the response SHOULD be:
FEATコマンド[RFC2389]に応答する場合、HOSTコマンドをサポートするサーバーFTPプロセスには、「HOST」という単一の単語を含む行を含める必要があります。この単語は大文字と小文字を区別しませんが、異なる実装との相互運用性を最大化するために大文字で送信する必要があります。つまり、応答は次のようにする必要があります。
C> FEAT
S> 211- <any descriptive text>
S> ...
S> HOST
S> ...
S> 211 End
The ellipses indicate placeholders where other features may be included but are not required. The one-space indentation of the feature lines is mandatory [RFC2389].
楕円は、他の機能を含めることができるが必須ではないプレースホルダーを示します。計画線の1スペースのインデントは必須です[RFC2389]。
As discussed in Section 3 of this document, a server implementation MUST treat an additional HOST command that was sent before a user has been authenticated as though a previous HOST command was not sent. In this situation, the server implementation MUST reset the authentication environment, as that would allow for segregation between the security environments for each virtual host on an FTP server. The implementation details for security environments may vary greatly based on the requirements of each server implementation and operating system, and those details are outside the scope of the protocol itself. For example, a virtual host "foo.example.com" on an FTP server might use a specific username and password list, while the virtual host "bar.example.com" on the same FTP server might use a different username and password list. In such a scenario, resetting the security environment is necessary for the virtual servers to appear to behave independently from a client perspective, while the actual server implementation details are irrelevant at the protocol level.
このドキュメントのセクション3で説明したように、サーバーの実装では、ユーザーが認証される前に送信された追加のHOSTコマンドを、以前のHOSTコマンドが送信されなかったかのように処理する必要があります。この状況では、サーバー実装は認証環境をリセットする必要があります。これにより、FTPサーバー上の各仮想ホストのセキュリティ環境間の分離が可能になります。セキュリティ環境の実装の詳細は、各サーバーの実装とオペレーティングシステムの要件に応じて大きく異なる可能性があり、それらの詳細はプロトコル自体の範囲外です。たとえば、FTPサーバー上の仮想ホスト「foo.example.com」は特定のユーザー名とパスワードのリストを使用し、同じFTPサーバー上の仮想ホスト「bar.example.com」は別のユーザー名とパスワードのリストを使用する場合があります。 。このようなシナリオでは、仮想サーバーがクライアントの観点から独立して動作しているように見えるようにセキュリティ環境をリセットする必要がありますが、実際のサーバー実装の詳細はプロトコルレベルでは無関係です。
Section 15.1.1 of [RFC4217] discusses the use of X.509 certificates for server authentication. Taking the information from that document into account, when securing FTP sessions with the security mechanisms that are defined in [RFC4217], client implementations SHOULD verify that the hostname that they specify in the parameter for the HOST command matches the identity that is specified in the server's X.509 certificate in order to prevent man-in-the-middle attacks.
[RFC4217]のセクション15.1.1では、サーバー認証にX.509証明書を使用する方法について説明しています。そのドキュメントの情報を考慮して、[RFC4217]で定義されているセキュリティメカニズムでFTPセッションを保護する場合、クライアント実装は、HOSTコマンドのパラメーターで指定するホスト名が、中間者攻撃を防ぐためのサーバーのX.509証明書。
When the HOST command is used in combination with the FTP security extensions that were introduced in [RFC2228] and [RFC4217], the HOST command SHOULD precede the security handshake when the user-PI is not providing the "server_name" in the extended client hello as defined in [RFC6066]. This allows both user-FTP and server-FTP processes to map an FTP HOST with the correct server name in the server's certificate. If the HOST command is sent after the security handshake, then mapping an FTP HOST to the correct security certificate will not take place before the secure session is established.
[RFC2228]と[RFC4217]で導入されたFTPセキュリティ拡張機能と組み合わせてHOSTコマンドを使用する場合、ユーザー-PIが拡張クライアントhelloで「server_name」を提供していない場合、HOSTコマンドはセキュリティハンドシェイクに先行する必要があります[RFC6066]で定義されています。これにより、ユーザーFTPプロセスとサーバーFTPプロセスの両方で、FTP HOSTをサーバーの証明書内の正しいサーバー名にマップできます。 HOSTコマンドがセキュリティハンドシェイクの後に送信された場合、セキュアセッションが確立される前に、FTP HOSTを正しいセキュリティ証明書にマッピングすることはできません。
For example, if a server-FTP process has multiple virtual hosts defined and no hostname has been sent from a user-FTP process, the server-FTP process will be unable to route the connection to the correct virtual host when the connection is established. In this situation, the server-FTP process will be forced to choose a virtual host that will respond. When the user-PI attempts to negotiate a secure connection, the virtual host to which the connection was routed will respond with its server certificate during the security handshake. If the virtual host that was chosen by the server-FTP process does not match the virtual host to which the user-FTP process had intended to connect, the user-PI will be unable to verify the server's identity as presented in the server certificate message.
たとえば、サーバーFTPプロセスに複数の仮想ホストが定義されていて、ユーザーFTPプロセスからホスト名が送信されていない場合、サーバーFTPプロセスは、接続が確立されたときに正しい仮想ホストに接続をルーティングできません。この状況では、サーバーFTPプロセスは、応答する仮想ホストを選択するように強制されます。ユーザーPIが安全な接続をネゴシエートしようとすると、接続がルーティングされた仮想ホストは、セキュリティハンドシェイク中にサーバー証明書で応答します。サーバーFTPプロセスによって選択された仮想ホストが、ユーザーFTPプロセスが接続しようとした仮想ホストと一致しない場合、ユーザーPIはサーバー証明書メッセージに示されているサーバーのIDを確認できません。
However, if the user-PI is providing the "server_name" in the extended client hello as defined in Section 3 of [RFC6066], the user-PI MAY provide the HOST command after the security handshake because the server will be able to route the connection to the correct virtual host based on the contents of the "server_name" extension and the client will be able to verify the server's identity as presented in the corresponding server certificate message. However, the server-PI MUST verify that the name in the HOST command matches the "server_name" that is provided in the extended client hello.
ただし、[RFC6066]のセクション3で定義されているように、user-PIが拡張クライアントhelloで「server_name」を提供している場合、サーバーはルーティングできるため、user-PIはセキュリティハンドシェイクの後にHOSTコマンドを提供できます（MAY）。 「server_name」拡張の内容に基づいて正しい仮想ホストに接続すると、クライアントは、対応するサーバー証明書メッセージに示されているサーバーのIDを確認できます。ただし、server-PIは、HOSTコマンドの名前が拡張クライアントhelloで提供される「server_name」と一致することを確認する必要があります。
In general, client implementations SHOULD protect user credentials by using the FTP security extensions that were introduced in [RFC2228] and [RFC4217]; a detailed discussion for securing FTP sessions can be found in those documents, and a general discussion of security issues related to FTP can be found in [RFC2577].
一般に、クライアントの実装は、[RFC2228]と[RFC4217]で導入されたFTPセキュリティ拡張機能を使用してユーザーの資格情報を保護する必要があります（SHOULD）。 FTPセッションを保護するための詳細な説明はこれらのドキュメントにあり、FTPに関連するセキュリティ問題の一般的な説明は[RFC2577]にあります。
IANA has registered the following FTP extension according to the procedure established by [RFC5797]:
IANAは、[RFC5797]によって確立された手順に従って、次のFTP拡張機能を登録しました。
+------+---------+-------------+------+------+----------------------+
| cmd | FEAT | description | type | conf | RFC#s/References and |
| | Code | | | | Notes |
+------+---------+-------------+------+------+----------------------+
| HOST | HOST | Hostname | a | o | RFC 7151 |
+------+---------+-------------+------+------+----------------------+
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[RFC959] Postel、J。およびJ. Reynolds、「File Transfer Protocol（FTP）」、STD 9、RFC 959、1985年10月。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、R。、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2228] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228, October 1997.
[RFC2228] Horowitz、M。およびS. Lunt、「FTP Security Extensions」、RFC 2228、1997年10月。
[RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998.
[RFC2389] Hethmon、P。およびR. Elz、「ファイル転送プロトコルの機能交渉メカニズム」、RFC 2389、1998年8月。
[RFC2640] Curtin, B., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999.
[RFC2640]カーティンB.、「ファイル転送プロトコルの国際化」、RFC 2640、1999年7月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October 2005.
[RFC4217] Ford-Hutchinson、P。、「Secureting FTP with TLS」、RFC 4217、2005年10月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年8月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066] Eastlake、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、2011年1月。
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC1945] Berners-Lee、T.、Fielding、R。、およびH. Nielsen、「Hypertext Transfer Protocol-HTTP / 1.0」、RFC 1945、1996年5月。
[RFC2577] Allman, M. and S. Ostermann, "FTP Security Considerations", RFC 2577, May 1999.
[RFC2577] Allman、M。、およびS. Ostermann、「FTP Security Considerations」、RFC 2577、1999年5月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface (CGI) Version 1.1", RFC 3875, October 2004.
[RFC3875] Robinson、D。およびK. Coar、「The Common Gateway Interface（CGI）Version 1.1」、RFC 3875、2004年10月。
[RFC5797] Klensin, J. and A. Hoenes, "FTP Command and Extension Registry", RFC 5797, March 2010.
[RFC5797] Klensin、J。およびA. Hoenes、「FTPコマンドおよび拡張レジストリ」、RFC 5797、2010年3月。
Due to the level of scope for adding a new command to FTP, a brief discussion of suggested alternatives to a HOST command and their respective limitations is warranted. The suggested alternatives that are discussed in this appendix have been proposed in the past, but each of these ideas was deemed insufficient for the reasons listed within each section of this appendix.
FTPに新しいコマンドを追加するスコープのレベルにより、HOSTコマンドの代替案とそれぞれの制限について簡単に説明します。この付録で説明されている代替案は過去に提案されていますが、これらの各アイデアは、この付録の各セクションに記載されている理由により不十分であると見なされました。
One suggested method to emulate a form of virtual hosts would be for the client to simply send a CWD command after connecting, using the virtual hostname as the argument to the CWD command. This would allow the server-FTP process to implement the file stores of the virtual hosts as subdirectories in its NVFS. This suggestion is simple in concept, and most server-FTP implementations support this without requiring any code changes. While this method is simple to describe and implement, it suffers from several drawbacks:
仮想ホストの形式をエミュレートするための1つの提案された方法は、接続後にクライアントがCWDコマンドの引数として仮想ホスト名を使用してCWDコマンドを送信することです。これにより、サーバーFTPプロセスは、仮想ホストのファイルストアをサブディレクトリとしてNVFSに実装できます。この提案は概念が単純であり、ほとんどのサーバーFTP実装は、コードを変更することなくこれをサポートします。この方法の説明と実装は簡単ですが、いくつかの欠点があります。
a. The CWD command is available only after the user-PI has authenticated itself to the server-FTP process. Thus, all virtual hosts would be required to share a common authentication scheme if they used this method.
a. CWDコマンドは、ユーザーPIがサーバーFTPプロセスに対して自身を認証した後でのみ使用できます。したがって、すべての仮想ホストは、この方法を使用する場合、共通の認証スキームを共有する必要があります。
b. To make the virtual host truly transparent, either the server-FTP process needs to be modified to include information that shows the special nature of this first CWD command (negating most of the advantage of this scheme), or all users must see the same identical NVFS view upon connecting (they must connect in the same initial directory), or the NVFS must implement the full set of virtual host directories at each possible initial directory for any possible user.
b. 仮想ホストを完全に透過的にするには、サーバーFTPプロセスを変更して、この最初のCWDコマンドの特別な性質を示す情報（このスキームの利点のほとんどを否定する）を含めるか、すべてのユーザーが同じものを見る必要があります接続時のNVFSビュー（同じ初期ディレクトリに接続する必要があります）、またはNVFSは、可能なすべてのユーザーの可能な初期ディレクトリごとに、仮想ホストディレクトリの完全なセットを実装する必要があります。
c. Unless the server is specially modified, a user connecting this way to a virtual host would be able to easily move to any other virtual host supported at the same server-FTP process, exposing the nature of the virtual host.
c. サーバーが特別に変更されていない限り、この方法で仮想ホストに接続しているユーザーは、同じサーバーのFTPプロセスでサポートされている他の仮想ホストに簡単に移動でき、仮想ホストの性質を公開できます。
Another suggested method would be to simply overload the ACCT command for FTP virtual hosts, but this proposal is unacceptable for several reasons with regard to when the ACCT command is sent during the request flow. Sections 5.4 and 6 of [RFC959] document the request flow for a login sequence as USER -> PASS -> ACCT. This flow of commands may be acceptable when you are considering a single user having multiple accounts on an FTP server, but it fails to differentiate between virtual hosts when you consider the following two issues:
別の提案された方法は、FTP仮想ホストのACCTコマンドを単純にオーバーロードすることですが、この提案は、要求フロー中にACCTコマンドが送信されるタイミングに関していくつかの理由で受け入れられません。 [RFC959]のセクション5.4および6は、ログインシーケンスのリクエストフローをUSER-> PASS-> ACCTとして文書化しています。このコマンドのフローは、FTPサーバーに複数のアカウントを持つ単一のユーザーを検討している場合は許容できますが、次の2つの問題を検討すると、仮想ホストを区別できません。
a. The first problem with overloading the ACCT command is certificate negotiation when using the FTP security extensions that are documented in [RFC2228] and [RFC4217]. In order to safeguard user credentials, negotiation of the security mechanism and certificate must occur before login credentials are sent by the client. The problem with using the ACCT command in this scenario is that there is no way of ensuring that the certificate matches the correct virtual host before the user credentials are sent.
a. ACCTコマンドのオーバーロードに関する最初の問題は、[RFC2228]および[RFC4217]で文書化されているFTPセキュリティ拡張機能を使用するときの証明書ネゴシエーションです。ユーザーの資格情報を保護するには、ログイン資格情報がクライアントから送信される前に、セキュリティメカニズムと証明書のネゴシエーションを行う必要があります。このシナリオでACCTコマンドを使用する場合の問題は、ユーザーの資格情報が送信される前に、証明書が正しい仮想ホストと一致することを確認する方法がないことです。
b. The second problem with overloading the ACCT command is how user credentials are implemented for FTP virtual hosts. FTP server implementations may allow the use of custom user credentials on a per-virtual-host basis. For example, in one particular implementation the virtual host negotiation occurs, and then the user credentials are looked up using the account mechanism that is specific to that virtual host. So once again the virtual host negotiation must take place before the user credentials are sent.
b. ACCTコマンドのオーバーロードに関する2番目の問題は、FTP仮想ホストにユーザー資格情報がどのように実装されるかです。 FTPサーバーの実装では、仮想ホストごとにカスタムユーザー資格情報を使用できる場合があります。たとえば、1つの特定の実装では、仮想ホストのネゴシエーションが発生し、その仮想ホストに固有のアカウントメカニズムを使用してユーザーの資格情報が検索されます。そのため、ユーザーの資格情報が送信される前に、仮想ホストのネゴシエーションを再度行う必要があります。
An additional suggestion would be to overload well-known syntax through the existing USER command, as illustrated in the following example:
追加の提案は、次の例に示すように、既存のUSERコマンドを介して既知の構文をオーバーロードすることです。
C> USER foo@example.com S> 331 Password required C> PASS bar S> 230 User logged in
C>ユーザーfoo@example.com S> 331パスワードが必要C>パスバーS> 230ユーザーがログイン
In this example, the user "foo" might be attempting to log on to the virtual host "example.com" on an FTP server. This suggestion may seem plausible at first, but it introduces several implementation problems. For example:
この例では、ユーザー「foo」がFTPサーバー上の仮想ホスト「example.com」にログオンしようとしている可能性があります。この提案は、最初はもっともらしく思えるかもしれませんが、いくつかの実装上の問題が生じます。例えば：
a. Some network environments already use the "username@hostname" syntax for network credentials, where the "hostname" portion refers to the location of the user's credentials within the network hierarchy. Using the "foo@example.com" syntax, it becomes difficult to differentiate between the user "foo" logging into a virtual host that is named "example.com" on an FTP server versus the user "foo@example.com" logging into an FTP server with no specified virtual host.
a. 一部のネットワーク環境では、ネットワーク資格情報に「username @ hostname」構文がすでに使用されています。「hostname」の部分は、ネットワーク階層内のユーザーの資格情報の場所を指します。 「foo@example.com」構文を使用すると、FTPサーバーで「example.com」という名前の仮想ホストにログインしているユーザー「foo」と、ユーザー「foo@example.com」のロギングを区別するのが難しくなります。仮想ホストが指定されていないFTPサーバーに。
b. When using the FTP security extensions that are documented in [RFC2228] and [RFC4217], negotiation of the security mechanism and certificate must occur before login credentials are sent by the client. More specifically, the AUTH/ADAT commands must be sent before the USER command in order to safeguard user credentials. If you overload the USER command, there is no way of ensuring that the certificate matches the correct virtual host before the user credentials are sent by the client.
b. [RFC2228]と[RFC4217]に記載されているFTPセキュリティ拡張機能を使用する場合、クライアントからログイン資格情報が送信される前に、セキュリティメカニズムと証明書のネゴシエーションを行う必要があります。より具体的には、ユーザーの資格情報を保護するために、AUTH / ADATコマンドをUSERコマンドの前に送信する必要があります。 USERコマンドをオーバーロードすると、クライアントからユーザーの資格情報が送信される前に、証明書が正しい仮想ホストと一致することを確認する方法がありません。
After examining the above alternatives, and in order to obtain an adequate emulation of "real" FTP servers, it was concluded that supporting virtual hosts will require both client and server modifications. Therefore, a new FTP command seems the most likely solution to provide the required level of support.
上記の代替案を検討した後、「実際の」FTPサーバーの適切なエミュレーションを取得するために、仮想ホストをサポートするにはクライアントとサーバーの両方の変更が必要であると結論付けられました。したがって、必要なレベルのサポートを提供する最も可能性の高いソリューションは、新しいFTPコマンドのようです。
Robert Elz and Paul Hethmon provided a detailed discussion of the HOST command in their Internet-Draft titled "Extensions to FTP" as part of their work with the FTPEXT Working Group of the IETF. Their work formed the basis for much of this document, and their help has been greatly appreciated. They would also like to credit Bernhard Rosenkraenzer for having first suggested and described the HOST command.
Robert ElzとPaul Hethmonは、IETFのFTPEXTワーキンググループとの共同作業の一環として、「Extensions to FTP」というタイトルのインターネットドラフトでHOSTコマンドの詳細について説明しました。彼らの仕事はこの文書の多くの基礎を形成し、彼らの助けは大いに感謝されました。彼らはまた、最初にHOSTコマンドを提案して説明したことについてBernhard Rosenkraenzerに感謝したいと思います。
Several people have provided a wealth of constructive feedback about earlier versions of this document that has helped to shape its development; many of their suggestions have been incorporated, and their contributions are gratefully acknowledged. There are far too many to mention here, but the authors of this document would like to specifically thank Alexey Melnikov, Alfred Hoenes, John Klensin, Joe Touch, Paul Ford-Hutchinson, Daniel Stenberg, Mykyta Yevstifeyev, Alec Rowell, Jaroslav Dunajsky, Wade Hilmo, Anthony Bryan, and Barry Leiba for their assistance.
何人かの人々が、このドキュメントの以前のバージョンについて、その開発を形作るのに役立つ豊富な建設的なフィードバックを提供してくれました。彼らの提案の多くは組み込まれており、彼らの貢献はありがたく認められています。ここで言及することは多すぎますが、このドキュメントの作成者は、アレクセイメルニコフ、アルフレッドホーネス、ジョンクレンシン、ジョータッチ、ポールフォードハッチンソン、ダニエルステンバーグ、ミキタイェフスティフェエフ、アレックローウェル、ヤロスラフドゥナイスキー、ウェイドに特に感謝しますHilmo、Anthony Bryan、Barry Leibaの各サポート。
Authors' Addresses
著者のアドレス
Paul Hethmon Hethmon Brothers 2305 Chukar Road Knoxville, TN 37923 USA
Paul Hethmon Hethmon Brothers 2305 Chukar Road Knoxville、TN 37923 USA
EMail: phethmon@hethmon.com
Robert McMurray Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
ろべｒｔ Ｍｃむっらｙ みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ うさ
EMail: robmcm@microsoft.com