Network Working Group P. Ford-Hutchinson
Request for Comments: 4217 IBM UK Ltd
Category: Standards Track October 2005
Securing FTP with TLS
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extensions to the FTP protocol defined by RFC 2228, "FTP Security Extensions". It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for Secure SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".
この文書は、RFC 2246で定義されたセキュリティおよびTLSプロトコルを使用して認証を実装するためにFTPクライアントとサーバで使用できるメカニズムを説明し、「TLSプロトコルバージョン1.0。」、およびRFC 2228で定義されたFTPプロトコルの拡張、 " FTPセキュリティ拡張機能」。それは、必要とされる拡張機能や使用するパラメータのサブセットを記述し、クライアントとサーバーが取る必要があります政策課題のいくつかを説明し、これらのポリシーの意味のいくつかを考慮し、実装のいくつかの期待される行動ができるように論じて相互運用。このドキュメントは、HTTP / 1.1内でTLSへのアップグレード」、RFC 2817で、およびHTTP「トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張」RFC 2487でSMTPのために提供されるものと同様の方法でFTPのTLSサポートを提供することを意図しています。 "。
This specification is in accordance with RFC 959, "File Transfer Protocol". It relies on RFC 2246, "The TLS Protocol Version 1.0.", and RFC 2228, "FTP Security Extensions".
この仕様はRFC 959、「ファイル転送プロトコル」に準拠しています。これは、RFC 2246に依存して、 "TLSプロトコルバージョン1.0。"、およびRFC 2228、 "FTPセキュリティ拡張機能"。
Table of Contents
目次
1. Introduction ....................................................3
2. Audience ........................................................5
3. Overview ........................................................5
4. Session Negotiation on the Control Port .........................5
4.1. Client Wants a Secured Session .............................5
4.2. Server Wants a Secured Session .............................6
5. Clearing the Control Port .......................................6
6. Response to the FEAT Command ....................................7
7. Data Connection Behaviour .......................................8
8. Mechanisms for the AUTH Command .................................9
9. Data Connection Security ........................................9
10. A Discussion of Negotiation Behaviour .........................11
10.1. The Server's View of the Control Connection ..............11
10.2. The Server's View of the Data Connection .................12
10.3. The Client's View of the Control Connection ..............14
10.4. The Client's View of the Data Connection .................15
11. Who Negotiates What, Where, and How ...........................15
11.1. Do we protect at all? ....................................15
11.2. What level of protection do we use on the Control
connection? ..............................................15
11.3. Do we protect data connections in general? ...............16
11.4. Is protection required for a particular data transfer? ...16
11.5. What level of protection is required for a
particular data ..........................................16
12. Timing Diagrams ...............................................16
12.1. Establishing a Protected Session .........................17
12.2. Establishing a Protected Session Without a
Password Request .........................................18
12.3. Establishing a Protected Session and then
Clearing with the CCC ....................................19
12.4. A Standard Data Transfer Without Protection ..............20
12.5. A Firewall-Friendly Data Transfer Without Protection .....20
12.6. A Standard Data Transfer with Protection .................21
12.7. A Firewall-Friendly Data Transfer with Protection ........21
13. Discussion of the REIN Command ................................22
14. Discussion of the STAT and ABOR Commands ......................22
15. Security Considerations .......................................23
15.1. Verification of Authentication Tokens ....................23
15.1.1. Server Certificates ...............................23
15.1.2. Client Certificates ...............................23
15.2. Addressing FTP Security Considerations [RFC-2577] ........24
15.2.1. Bounce Attack .....................................24
15.2.2. Restricting Access ................................24
15.2.3. Protecting Passwords ..............................24
15.2.4. Privacy ...........................................24
15.2.5. Protecting Usernames ..............................24
15.2.6. Port Stealing .....................................25
15.2.7. Software-Based Security Problems ..................25
15.3. Issues with the CCC Command ..............................25
16. IANA Considerations ...........................................25
17. Other Parameters ..............................................25
18. Scalability and Limits ........................................26
19. Applicability .................................................26
20. Acknowledgements ..............................................26
21. References ....................................................26
21.1. Normative References .....................................26
21.2. Informative References ...................................27
This document describes how three other documents should be combined to provide a useful, interoperable, and secure file transfer protocol. Those documents are:
この文書は、他の三つの文書は、便利な相互運用可能、かつ安全なファイル転送プロトコルを提供するために結合する方法を説明します。これらの文書は、次のとおりです。
RFC 959 [RFC-959]
RFC 959 [RFC-959]
The description of the Internet File Transfer Protocol.
インターネットファイル転送プロトコルの記述。
RFC 2246 [RFC-2246]
RFC 2246 [RFC-2246]
The description of the Transport Layer Security protocol (developed from the Netscape Secure Sockets Layer (SSL) protocol version 3.0).
（ネットスケープのSecure Sockets Layer（SSL）プロトコルのバージョン3.0から開発）トランスポート層セキュリティプロトコルの記述。
RFC 2228 [RFC-2228]
RFC 2228 [RFC-2228]
Extensions to the FTP protocol to allow negotiation of security mechanisms to allow authentication, confidentiality, and message integrity.
認証、機密性、およびメッセージの整合性を可能にするために、セキュリティ・メカニズムの交渉を許可するFTPプロトコルの拡張。
This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 3207 [RFC-3207] and HTTP in RFC 2817 [RFC-2817].
この文書は、RFC 2817 [RFC-2817]においてRFC 3207 [RFC-3207]及びHTTPにSMTPのために設けられたものと同様の方法でFTPのTLSサポートを提供することを目的とします。
The security extensions to FTP in [RFC-2228] offer a comprehensive set of commands and responses that can be used to add authentication, integrity, and confidentiality to the FTP protocol. The TLS protocol is a popular (due to its wholesale adoption in the HTTP environment) mechanism for generally securing a socket connection.
[RFC-2228]でFTPへのセキュリティ拡張機能は、FTPプロトコルに認証、整合性、および機密性を追加するために使用できるコマンドと応答の包括的なセットを提供します。 TLSプロトコルは、一般的にソケット接続を確保するためのメカニズム（原因HTTP環境での卸売採用に）人気があります。
Although TLS is not the only mechanism for securing file transfer, it does offer some of the following positive attributes:
TLSは、ファイル転送を確保するための唯一のメカニズムではありませんが、それは以下の正の属性のいくつかを提供しません。
- Flexible security levels. TLS can support confidentiality, integrity, authentication, or some combination of all of these. During a session, this allows clients and servers to dynamically decide on the level of security required for a particular data transfer.
- 柔軟なセキュリティレベル。 TLSは、機密性、完全性、認証、またはこれらの全ての組み合わせをサポートすることができます。セッション中に、これは、クライアントとサーバが動的に特定のデータ転送に必要なセキュリティのレベルを決定することができます。
- Ability to provide strong authentication of the FTP server.
- FTPサーバの強力な認証を提供する能力。
- It is possible to use TLS identities to authenticate client users and client hosts.
- クライアントのユーザーとクライアントホストを認証するためにTLSのIDを使用することが可能です。
- Formalised public key management. By use of well established client identity mechanisms (supported by TLS) during the authentication phase, certificate management may be built into a central function. Whilst this may not be desirable for all uses of secured file transfer, it offers advantages in certain structured environments.
- 公開鍵管理を正式な。認証フェーズ（TLSによってサポートされる）十分に確立されたクライアント識別メカニズムを使用することによって、証明書管理は、中央の機能に組み込まれてもよいです。これは、安全なファイル転送のすべての使用のために望ましいことではないかもしれないが、それは特定の構造化された環境での利点を提供しています。
- Co-existence and interoperation with authentication mechanisms that are already in place for the HTTPS protocol. This allows web browsers to incorporate secure file transfer using the same infrastructure that has been set up to allow secure web browsing.
- HTTPSプロトコルのためにすでに配置されている認証メカニズムとの共存と相互運用。これは、WebブラウザがセキュアなWebブラウジングを許可するように設定されている同じインフラストラクチャを使用してセキュアなファイル転送を組み込むことができます。
The TLS protocol is a development of the Netscape Communication Corporation's SSL protocol and this document can be used to allow the FTP protocol to be used with either SSL or TLS. The actual protocol used will be decided by the negotiation of the protected session by the TLS/SSL layer. This document will only refer to the TLS protocol; however, it is understood that the Client and Server MAY actually be using SSL if they are so configured.
TLSプロトコルは、Netscape通信社のSSLプロトコルの開発であり、この文書は、FTPプロトコルがSSLやTLSのいずれかで使用されることを可能にするために使用することができます。使用される実際のプロトコルは、TLS / SSL層によって保護されたセッションの交渉によって決定されます。この文書では、TLSプロトコルを指します。しかし、彼らがそのように構成されている場合、クライアントとサーバーが実際にSSLを使用してもよいことが理解されます。
There are many ways in which these three protocols can be combined. This document selects one method by which FTP can operate securely, while providing both flexibility and interoperation. This necessitates a brief description of the actual negotiation mechanism, a detailed description of the required policies and practices, and a discussion of the expected behaviours of clients and servers to allow either party to impose their security requirements on the FTP session.
これら3つのプロトコルを組み合わせることができる多くの方法があります。この文書では、柔軟性および相互運用の両方を提供しながら、FTPは、確実に動作することができる1つの方法を選択します。これは、いずれかの当事者が、FTPセッションで彼らのセキュリティ要件を課すことができるように、実際の交渉メカニズム、必要な政策や慣行の詳細な説明、およびクライアントとサーバの予想行動の議論の簡単な説明を必要とします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" that appear in this document are to be interpreted as described in [RFC-2119].
この文書に現れるキーワード「MUST」、「MUST NOT」、「REQUIRED」、、、、「べきではない」「べきである」「ないもの」「ものとし」、「推奨」、「MAY」と「オプション」 [RFC-2119]に記載されているように解釈されるべきです。
This document is aimed at developers who wish to implement TLS as a security mechanism to secure FTP clients and/or servers.
この文書は、FTPクライアントおよび/またはサーバを保護するためのセキュリティメカニズムとして、TLSを実装する開発者を対象としています。
Systems administrators and architects should be fully aware of the security implications discussed in [RFC-2228], which need to be considered when choosing an implementation of this protocol and configuring it to provide their required security.
システム管理者やアーキテクトは、このプロトコルの実装を選択し、自分の必要なセキュリティを提供するために、それを構成する際に考慮する必要がある[RFC-2228]で議論セキュリティへの影響、を十分に認識する必要があります。
A full description of the FTP security protocol enhancements is contained in [RFC-2228]. This document describes how the AUTH, PROT, PBSZ, and CCC commands, defined therein, should be implemented with the TLS protocol.
FTPセキュリティプロトコル拡張の完全な説明は、[RFC-2228]に含まれています。この文書では、その中に画定され、どのAUTH、PROT、PBSZ、およびCCCコマンドについて説明し、TLSプロトコルで実装されるべきです。
In summary, an FTP session is established on the normal control port. A client requests TLS with the AUTH command and then decides if it wishes to secure the data connections by use of the PBSZ and PROT commands. Should a client wish to make the control connection revert back into plaintext (for example, once the authentication phase is completed), then the CCC command can be used.
要約すると、FTPセッションは、通常の制御ポートに確立されています。クライアントがAUTHコマンドでTLSを要求し、それがPBSZとPROTコマンドを使用してデータ接続を確保したい場合に決定します。クライアントが（認証フェーズが完了すると、例えば）制御接続を平文に戻すにしたいはずですし、CCCコマンドを使用することができます。
Implementation of this protocol extension does not ensure that each and every session and data transfer is secure, it merely provides the tools that allow a client and/or server to negotiate an acceptable or required level of security for that given session or data transfer. However, it is possible to have a server implementation that is capable of refusing to operate in an insecure fashion.
このプロトコル拡張の実装は、それは単に、クライアントおよび/またはサーバがその特定のセッションやデータ転送のためのセキュリティの許容または必要なレベルを交渉することを可能にするツールを提供し、それぞれ、すべてのセッションとデータ転送が安全であることを保証しません。しかし、安全でない方法で動作することを拒否することができ、サーバの実装を持つことが可能です。
The server listens on the normal FTP control port {FTP-PORT} and the session initiation is not secured at all. Once the client wishes to secure the session, the AUTH command is sent and the server MAY then allow TLS negotiation to take place.
サーバは、通常のFTP制御ポート{FTP-PORT}をリッスンし、セッション開始は全く確保されていません。クライアントがセッションを確保することを希望すると、AUTHコマンドが送信され、その後、サーバはTLS交渉が行われることを可能にします。
If a client wishes to attempt to secure a session, then it SHOULD, in accordance with [RFC-2228], send the AUTH command with the parameter requesting TLS {TLS-PARM} ('TLS').
クライアントがセッションを確保しようとすることを望む場合、それは、[RFC-2228]に従って、TLS {TLS-PARM}（「TLS」）を要求するパラメータでAUTHコマンドを送信すべきです。
The client then needs to behave according to its policies depending on the response received from the server and also the result of the TLS negotiation. A client that receives an AUTH rejection MAY choose to continue with the session unprotected if it so desires.
次に、クライアントは、サーバともTLS交渉の結果から受信した応答に応じて、その方針に従って行動する必要があります。 AUTH拒絶反応を受けるクライアントは、それがそう望む場合に保護されていないセッションを続行するように選択できます。
The FTP protocol does not allow a server to directly dictate client behaviour; however, the same effect can be achieved by refusing to accept certain FTP commands until the session is secured to a level that is acceptable to the server.
FTPプロトコルは、サーバが直接クライアントの動作を指示することはできません。しかし、同様の効果は、セッションがサーバに受け入れられるレベルに固定されるまで、特定のFTPコマンドを受け入れることを拒否することによって達成することができます。
In either case, '234' is the server response to an 'AUTH TLS' command that it will honour.
いずれの場合も、「234」は、それが尊重することを「AUTH TLS」コマンドに対するサーバの応答です。
The '334' response, as defined in [RFC-2228], implies that an ADAT exchange will follow. This document does not use the ADAT command and so the '334' reply is incorrect.
「334」応答は、[RFC-2228]で定義されるように、ADAT交換が続くことを意味します。この文書では、ADATコマンドを使用していないので、「334」応答が正しくありません。
The FTP protocol insists that a USER command be used to identify the entity attempting to use the ftp server. Although the TLS negotiation may be providing authentication information, the USER command MUST still be issued by the client. However, it will be a server implementation issue to decide which credentials to accept and what consistency checks to make between the client cert used and the parameter on the USER command.
FTPプロトコルは、USERコマンドはftpサーバを使用しようとするエンティティを識別するために使用されることを主張しています。 TLSネゴシエーションが認証情報を提供することができるが、USERコマンドは、まだクライアントによって発行されなければなりません。しかし、受け入れるために、使用するクライアント証明書とUSERコマンドのパラメータの間でどのような一貫性のチェックをするためにどの資格情報を決定するために、サーバの実装の問題になります。
[RFC-2228] states that the user must reauthorize (that is, reissue some or all of the USER, PASS, and ACCT commands) following an AUTH command. Additionally, this document specifies that all other transfer parameters (other than the AUTH parameter) must be reset, almost as if a REIN command was issued.
[RFC-2228は、ユーザがAUTHコマンド以下（すなわち、USER、PASS、およびACCTコマンドの一部または全部を再発行された）再認証する必要があることを述べています。また、この文書は（AUTHパラメータ以外の）他のすべての転送パラメータは、REINコマンドが発行されたほとんどかのように、リセットする必要があることを指定します。
Reset transfer parameters after the AUTH command, including (but are not limited to): user identity, default data ports, TYPE, STRU, MODE, and current working directory.
ユーザアイデンティティ、デフォルトのデータポート、TYPE、STRU、MODE、および現在の作業ディレクトリ：含む（しかし、これらに限定されない）、AUTHコマンドの後に転送パラメータをリセットします。
There are circumstances in which it may be desirable to protect the control connection only during part of the session and then to revert back to a plaintext connection. This is often due to the limitations of boundary devices such as NAT and firewalls, which expect to be able to examine the content of the control connection in order to modify their behaviour.
セッションの一部の間のみ制御接続を保護し、次いで、平文接続に戻すことが望ましいかもしれないような状況があります。これは、多くの場合、彼らの行動を修正するために、制御接続の内容を調べることができることを期待し、このようなNATやファイアウォールなどの境界デバイスの制限によるものです。
Typically the AUTH, USER, PASS, PBSZ, and PROT commands would be protected within the TLS protocol and then the CCC command would be issued to return to a plaintext socket state. This has important Security Issues (which are discussed in the Security Considerations section), but this document describes how the command should be used, if the client and server still wish to use it after having considered the issues.
典型的には、AUTH、USER、PASS、PBSZ、およびPROTコマンドは、TLSプロトコル内で保護されると、次にCCCコマンドが平文ソケットの状態に戻すために発行されることになります。これは、（セキュリティの考慮事項のセクションで説明されている）の重要なセキュリティ問題がありますが、クライアントとサーバがまだ問題を検討した後、それを使用したい場合は、この文書では、コマンドを使用する方法について説明します。
When a server receives the CCC command, it should behave as follows:
サーバーは、CCCコマンドを受信すると、次のように振る舞う必要があります。
If the server does not accept CCC commands (or does not understand them), then a 500 reply should be sent.
サーバーは、CCCコマンドを受け付けません（またはそれらを理解していない）場合は、500応答が送られるべきです。
Otherwise, if the control connection is not protected with TLS, then a 533 reply should be sent.
制御接続はTLSで保護されていない場合、そうでない場合、次いで533応答が送信されるべきです。
Otherwise, if the server does not wish to allow the control connection to be cleared at this time, then a 534 reply should be sent.
サーバーが制御接続は、この時点でクリアできるようにしたくない場合はそれ以外の場合は、その後、534応答が送られるべきです。
Otherwise, the server is accepting the CCC command and should do the following:
そうしないと、サーバはCCCコマンドを受け入れて、次の操作を行う必要があります。
o Send a 200 reply.
O 200応答を送信します。
o Shutdown the TLS session on the socket and leave it open.
シャットダウンOソケットのTLSセッションと開いたままにしておきます。
o Continue the control connection in plaintext, expecting the next command from the client to be in plaintext.
O平文であることを、クライアントからの次のコマンドを期待して、平文で制御接続を続行します。
o Not accept any more PBSZ or PROT commands. All subsequent data transfers must be protected with the current PROT settings.
Oこれ以上PBSZまたはPROTコマンドを受け入れるわけではありません。その後のすべてのデータ転送は、現在PROT設定で保護されなければなりません。
The FEAT command (introduced in [RFC-2389]) allows servers with additional features to advertise these to a client by responding to the FEAT command. If a server supports the FEAT command, then it MUST advertise supported AUTH, PBSZ, and PROT commands in the reply, as described in section 3.2 of [RFC-2389]. Additionally, the AUTH command should have a reply that identifies 'TLS' as one of the possible parameters to AUTH. It is not necessary to identify the 'TLS-C' synonym separately.
（[RFC-2389]で導入された）FEATコマンドが追加機能を持つサーバは、FEATコマンドに応答して、クライアントにこれらを宣伝することができます。サーバがFEATコマンドをサポートしている場合は、[RFC-2389]のセクション3.2で説明したように、それはサポートさアドバタイズする必要がありAUTH、PBSZ、およびPROTは、回答にコマンド。また、AUTHコマンドは、AUTHに可能なパラメータの1つとして「TLS」を特定する返信を持っている必要があります。別途「TLS-C」同義語を特定する必要はありません。
Example reply (in the same style as [RFC-2389])
（[RFC-2389]と同じ様式で）実施例返信
C> FEAT S> 211-Extensions supported S> AUTH TLS S> PBSZ S> PROT S> 211 END
C> FEAT S> 211-拡張機能は、S> AUTH TLS S> PBSZ S> PROT S> 211 ENDをサポート
The Data Connection in the FTP model can be used in one of three ways. (Note: These descriptions are not necessarily placed in exact chronological order, but do describe the steps required. See diagrams later for clarification.)
FTPモデルのデータ接続は、3つの方法の1つで使用することができます。 （注：これらの記述は、必ずしも正確な年代順に配置されていませんが、必要な手順を説明しない明確化するための図、後で参照してください。）
i) Classic FTP client/server data exchange
ⅰ）クラシックFTPクライアント/サーバーのデータ交換
- The client obtains a port; sends the port number to
the server; the server connects to the client. The
client issues a send or receive request to the server
on the control connection and the data transfer
commences on the data connection.
ii) Firewall-Friendly client/server data exchange (as discussed in [RFC-1579]) using the PASV command to reverse the direction of the data connection.
データ接続の方向を逆にPASVコマンドを使用して説明したようにII）ファイアウォール・フレンドリークライアント/サーバ・データ交換（[RFC-1579]）。
- The client requests that the server open a port; the
server obtains a port and returns the address and
port number to the client; the client connects to the
server on this port. The client issues a send or
receive request on the control connection, and the
data transfer commences on the data connection.
iii) Client-initiated server/server data exchange (proxy or PASV connections).
III）クライアントが開始サーバー/サーバー・データ交換（プロキシまたはPASV接続）。
- The client requests that server A opens a port;
server A obtains a port and returns it to the client;
the client sends this port number to server B.
Server B connects to server A. The client sends a
send or receive request to server A and the
complement to server B and the data transfer
commences. In this model, server A is the proxy or
PASV host and is a client for the Data Connection to
server B.
For i) and ii), the FTP client MUST be the TLS client and the FTP server MUST be the TLS server.
I）およびii）の場合は、FTPクライアントがTLSクライアントでなければなりませんし、FTPサーバがTLSサーバでなければなりません。
That is to say, it does not matter which side initiates the connection with a connect() call or which side reacts to the connection via the accept() call; the FTP client, as defined in [RFC-959], is always the TLS client, as defined in [RFC-2246].
それは受け入れ（）呼び出しを介して接続に反応する側呼び出すか）（接続との接続を開始する側の問題ではありません、と言うことです。 FTPクライアントは、[RFC-959]で定義されるように、[RFC-2246]で定義されているように、常にTLSクライアントです。
In scenario iii), there is a problem in that neither server A nor server B is the TLS client, given the fact that an FTP server must act as a TLS server for Firewall-Friendly FTP [RFC-1579]. Thus, this is explicitly excluded in the security extensions document [RFC-2228] and in this document.
シナリオIII）では、そのサーバーAとサーバーのいずれもBでの問題は、FTPサーバーがファイアウォール・フレンドリーFTP [RFC-1579]のためのTLSサーバとして機能しなければならないという事実を考えると、TLSクライアントがされています。したがって、これは明示的にセキュリティ拡張ドキュメント[RFC-2228]で、この文書では除外されています。
The AUTH command takes a single parameter to define the security mechanism to be negotiated. As the SSL/TLS protocols self-negotiate their levels, there is no need to distinguish between SSL and TLS in the application layer. The mechanism name for negotiating TLS is the character string identified in {TLS-PARM}. This allows the client and server to negotiate TLS on the control connection without altering the protection of the data channel. To protect the data channel as well, the PBSZ command, followed by the PROT command sequence, MUST be used.
AUTHコマンドは、ネゴシエートするセキュリティ・メカニズムを定義するために、単一のパラメータを取ります。 SSL / TLSは、自己交渉彼らのレベルをプロトコルなど、アプリケーション層でSSLとTLSを区別する必要はありません。 TLSを交渉するためのメカニズム名は{TLS-PARM}で識別された文字列です。これは、クライアントとサーバーがデータ・チャネルの保護を変更することなく、制御接続にTLSを交渉することができます。同様にデータ・チャネルを保護するために、PROTコマンドシーケンスが続くPBSZコマンドは、使用しなければなりません。
Note: The data connection state MAY be modified by the client issuing the PROT command with the new desired level of data channel protection and the server replying in the affirmative. This data channel protection negotiation can happen at any point in the session (even straight after a PORT or PASV command) and as often as is required.
注意：データ接続状態は、データチャネルの保護と肯定的に回答するサーバーの新しい所望のレベルでPROTコマンドを発行したクライアントによって変更されるかもしれません。このデータチャネル保護交渉は、頻繁に必要とされるような（でもストレートPORTまたはPASVコマンドの後）セッション中に任意の時点で起こるとすることができます。
See also Section 16, "IANA Considerations".
、セクション16も「IANAの考慮事項」を参照してください。
The Data Connection security level is determined by the PROT command.
データ接続のセキュリティレベルはPROTコマンドによって決定されます。
The PROT command, as specified in [RFC-2228], allows client/server negotiation of the security level of the data connection. Once a PROT command has been issued by the client and accepted by the server returning the '200' reply, the security of subsequent data connections MUST be at that level until another PROT command is issued and accepted; the session ends and a REIN command is issued, or the security of the session (via an AUTH command) is re-negotiated.
PROTコマンドは、[RFC-2228]で指定され、データ接続のセキュリティ・レベルのクライアント/サーバのネゴシエーションを可能にします。 PROTコマンドがクライアントによって発行されたと「200」回答を返すサーバーによって承認された後、別のPROTコマンドが発行され、受け入れられるまで、後続のデータ接続のセキュリティは、そのレベルでなければなりません。セッションが終了し、REINコマンドが発行され、または（AUTHコマンドを使って）セッションのセキュリティは、再交渉されます。
Data Connection Security Negotiation (the PROT command)
データ接続のセキュリティネゴシエーション（PROTコマンド）
Note: In line with [RFC-2228], there is no facility for securing the Data connection with an insecure Control connection. Specifically, the PROT command MUST be preceded by a PBSZ command, and a PBSZ command MUST be preceded by a successful security data exchange (the TLS negotiation in this case).
注：[RFC-2228]に沿って、安全でないコントロール接続とのデータ接続を固定するための設備がありません。具体的には、PROTコマンドはPBSZコマンドによって先行されなければならない、とPBSZコマンドが成功したセキュリティデータ交換（この場合、TLSネゴシエーション）が先行されなければなりません。
The command defined in [RFC-2228] to negotiate data connection security is the PROT command. As defined, there are four values that the PROT command parameter can take.
データ接続セキュリティをネゴシエートする[RFC-2228]で定義されたコマンドはPROTコマンドです。定義されているように、PROTコマンドパラメータが取ることができる4つの値があります。
'C' - Clear - neither Integrity nor Privacy
「C」 - クリア - 整合性もプライバシーもありません
'S' - Safe - Integrity without Privacy
「S」 - 金庫 - プライバシーなしの整合性
'E' - Confidential - Privacy without Integrity
「E」 - 秘密 - 整合性のないプライバシー
'P' - Private - Integrity and Privacy
「P」 - プライベート - 整合性とプライバシー
As TLS negotiation encompasses (and exceeds) the Safe / Confidential / Private distinction, only Private (use TLS) and Clear (don't use TLS) are used.
金庫/秘密/プライベートの区別TLSネゴシエーションが含まれる（および超える）として、唯一のプライベート（TLSを使用）とクリア（TLSを使用していない）が使用されています。
For TLS, the data connection can have one of two security levels.
TLSの場合は、データ接続は、2つのセキュリティレベルのいずれかを持つことができます。
1) Clear (requested by 'PROT C')
1）クリア（ 'PROTのC'）によって要求
2) Private (requested by 'PROT P')
2）プライベート（ 'PROTのP'）によって要求されました
With 'Clear' protection level, the data connection is made without TLS. Thus, the connection is unauthenticated and has no confidentiality or integrity. This might be the desired behaviour for servers sending file lists, pre-encrypted data, or non-sensitive data (e.g., for anonymous FTP servers).
「クリア」保護レベルでは、データ接続は、TLSなしで行われます。このため、接続が認証されていないし、何の機密性や完全性を持っていません。これは、ファイルリスト、事前に暗号化されたデータ、または非機密データを送信するサーバのための望ましい行動かもしれません（例えば、匿名FTPサーバー用）。
If the data connection security level is 'Private', then a TLS negotiation must take place on the data connection to the satisfaction of the Client and Server prior to any data being transmitted over the connection. The TLS layers of the Client and Server will be responsible for negotiating the exact TLS Cipher Suites that will be used (and thus the eventual security of the connection).
データ接続のセキュリティレベルが「プライベート」である場合には、TLSネゴシエーションは接続を介して送信されているすべてのデータの前にクライアントとサーバーの満足度へのデータ接続上で行わなければなりません。クライアントとサーバーのTLS層は（したがって、接続の最終的なセキュリティをして）使用される正確なTLS暗号スイートを交渉する責任を負います。
In addition, the PBSZ (protection buffer size) command, as detailed in [RFC-2228], is compulsory prior to any PROT command. This document also defines a data channel encapsulation mechanism for protected data buffers. For FTP-TLS, which appears to the FTP application as a streaming protection mechanism, this is not required. Thus, the PBSZ command MUST still be issued, but must have a parameter of '0' to indicate that no buffering is taking place and the data connection should not be encapsulated.
また、PBSZ（保護バッファサイズ）コマンドは、[RFC-2228]に詳述されるように、前の任意のPROTコマンドに強制的です。また、このドキュメントでは、保護されたデータ・バッファのデータ・チャネル・カプセル化メカニズムを定義します。ストリーミング保護メカニズムとしてFTPアプリケーションに表示されるFTP-TLSについては、これは必須ではありません。このように、PBSZコマンドがまだ発行されている必要がありますが、何のバッファリングが行われていないと、データ接続がカプセル化されるべきでないことを示すために、「0」のパラメータを持っている必要があります。
Note that PBSZ 0 is not in the grammar of [RFC-2228], section 8.1, where it is stated:
PBSZ 0は、それが記載されている[RFC-2228]、セクション8.1の文法ではないことに留意されたいです。
PBSZ <sp> <decimal-integer> <CRLF> <decimal-integer> ::= any
decimal integer from 1 to (2^32)-1
However, it should be noted that using a value of '0' to mean a streaming protocol is a reasonable use of '0' for that parameter and is not ambiguous.
しかし、ストリーミングプロトコルを意味する「0」の値を使用すると、そのパラメータの「0」の合理的な使用であると曖昧でないことに留意すべきです。
Initial Data Connection Security
初期データ接続のセキュリティ
The initial state of the data connection MUST be 'Clear' (this is the behaviour as indicated by [RFC-2228]).
データ接続の初期状態は「クリア」する必要があります（これはによって示されるように挙動は、[RFC-2228]）。
As [RFC-2228] allows security qualities to be negotiated, enabled, and disabled dynamically, this can make implementations seem quite complex. However, in any given instance the behaviour should be quite straightforward. Either the server will be enforcing the policy of the server host or it will be providing security capabilities requested by the client. Either the client will be conforming to the server's policy or will be endeavouring to provide the capabilities that the user desires.
[RFC-2228]は、セキュリティの品質は、交渉し有効に、かつ動的に無効にすることができますように、これは実装が非常に複雑に見えることができます。しかし、任意の特定のインスタンスで動作は非常に簡単でなければなりません。どちらのサーバがサーバホストのポリシーを適用されるか、それがクライアントによって要求されたセキュリティ機能を提供します。どちらのクライアントは、サーバのポリシーに準拠されるか、ユーザーが希望する機能を提供するために努力します。
A server MAY have a policy statement somewhere that might:
サーバーはどこかかもしれないポリシーステートメントを持っていることがあります。
- Deny any command before TLS is negotiated (this might cause problems if a SITE or some such command is required prior to login).
- TLSが交渉される前に（SITEまたはそのようないくつかのコマンドは、ログインする前に必要とされる場合、これは問題を引き起こす可能性があります）任意のコマンドを拒否します。
- Deny certain commands before TLS is negotiated (e.g., USER, PASS, or ACCT).
- TLSは、（例えば、USER、PASS、またはACCT）ネゴシエートされる前に特定のコマンドを拒否します。
- Deny insecure USER commands for certain users (e.g., not ftp/anonymous).
- 特定のユーザ（例えば、FTP /匿名ではない）のために安全でないユーザコマンドを拒否する。
- Deny secure USER commands for certain users (e.g., ftp/anonymous).
- 特定のユーザ（例えば、FTP /匿名）のためのセキュアなユーザ・コマンドを拒否する。
- Define the level(s) of TLS to be allowed.
- 許可するTLSのレベル（複数可）を定義します。
- Define the CipherSuites allowed to be used (perhaps on a per host/domain/... basis).
- （おそらくあたりのホスト/ドメイン/ ...基づいて）使用することが許可されているCipherSuiteを定義します。
- Allow TLS authentication as a substitute for local authentication.
- ローカル認証の代替としてTLS認証を許可します。
- Define data connection policies (see next section).
- （次のセクションを参照）データ接続ポリシーを定義します。
It is possible that the TLS negotiation may not be completed satisfactorily for the server, in which case it can be one of these states.
TLSネゴシエーションが、それはこれらの状態のいずれかにすることができ、その場合には、サーバーのために満足に完了されない可能性があります。
The TLS negotiation failed completely
TLS交渉が完全に失敗しました
In this case, the control connection should still be in an unprotected mode and the server SHOULD issue an unprotected '421' reply to end the session.
この場合、制御接続は、まだ保護されていないモードにする必要がありますし、サーバーがセッションを終了するには、保護されていない「421」応答を発行する必要があります。
The TLS negotiation completed successfully, but the server decides that the session parameters are not acceptable (e.g., Distinguished Name in the client certificate is not permitted to use the server).
TLSネゴシエーションが正常に完了しましたが、サーバーはセッションパラメータは、（例えば、クライアント証明書内の識別名は、サーバーの使用が許可されていません）許容できないと判断しました。
In this case, the control connection should still be in a protected state, so the server MAY either continue to refuse to service commands or issue a protected '421' reply and close the connection.
サーバがサービスコマンドを拒否し続けるか、保護された「421」応答を発行し、接続を閉じてもよい（MAY）のいずれかのように、この場合、制御接続はまだ、保護された状態でなければなりません。
The TLS negotiation failed during the TLS handshake
TLS交渉はTLSハンドシェイク中に失敗しました
In this case, the control connection is in an unknown state and the server SHOULD simply drop the control connection.
この場合、制御接続が未知の状態にあり、サーバは単に制御接続をドロップすべきです。
The server code will be responsible for implementing the required policies and ensuring that the client is prevented from circumventing the chosen security by refusing to service those commands that are against policy.
サーバコードは、必要な政策を実施し、クライアントがポリシーに反するこれらのコマンドのサービスを拒否によって選ばれたセキュリティを回避することが防止されることを保証する責任となります。
The server can take one of four basic views of the data connection.
サーバーは、データ接続の四つの基本的なビューのいずれかを取ることができます。
1 - Don't allow encryption at all (in which case the PROT command should not allow any value other than 'C' - if it is allowed at all).
1 - すべて（その場合にはPROTコマンドは「C」以外の値を許可してはならない - それがすべてで許可されている場合）で暗号化を許可しないでください。
2 - Allow the client to choose protection or not.
2 - クライアントが保護を選択するか、しないように許可します。
3 - Insist on data protection (in which case the PROT command must be issued prior to the first attempted data transfer).
3 - データ保護を主張（その場合にはPROTコマンドは、前に最初に試みのデータ転送に発行する必要があります）。
4 - Decide on one of the above three for each and every data connection.
4 - それぞれ、すべてのデータ接続のための上記の3つのいずれかを決定します。
The server SHOULD only check the status of the data protection level (for options 3 and 4 above) on the actual command that will initiate the data transfer (and not on the PORT or PASV). The following commands, defined in [RFC-959], cause data connections to be opened and thus may be rejected before any 1xx message due to an incorrect PROT setting.
サーバは、（PORTまたはPASVではなく）データ転送を開始する実際のコマンドに（オプション上記3及び4）データ保護レベルのステータスをチェックしてください。 [RFC-959]で定義された次のコマンドは、データ接続が開放されるので、誤っPROT設定に任意の1xxメッセージの前に拒否することができる引き起こします。
STOR
RETR
NLST
LIST
STOU
APPE
The reply to indicate that the PROT setting is incorrect is '521 data connection cannot be opened with this PROT setting'
PROTの設定が間違っていることを示すために、回答は「521データ接続がこのPROT設定で開くことができない」です
If the protection level indicates that TLS is required, then it should be negotiated once the data connection is made. Thus, the '150' reply only states that the command can be used given the current PROT level. Should the server not like the TLS negotiation, then it will close the data port immediately and follow the '150' command with a '522' reply, which indicates that the TLS negotiation failed or was unacceptable. (Note: This means that the application can pass a standard list of CipherSuites to the TLS layer for negotiation, and review the one negotiated for applicability in each instance).
保護レベルは、TLSが必要であることを示している場合は、データ接続が行われると、それが交渉されるべきです。したがって、「150」の応答は、コマンドが現在のPROTレベル与え使用することができると述べています。サーバがTLSネゴシエーションを好きではないはずです、それはすぐにデータポートを閉じて、TLS交渉が失敗したか、または受け入れられなかったことを示している「522」の返信、と150「」コマンドに従います。 （注：これは、アプリケーションがネゴシエーションTLS層に暗号スイートの標準的なリストを渡し、各インスタンスに適用のために交渉いずれかを見直すことができることを意味します）。
The Security Considerations section discusses the issue of cross-checking any certificates used to authenticate the data connection with the one(s) used to authenticate the control connection. This is an important security step.
Security Considerations部は、制御接続を認証するために使用される1（S）とのデータ接続を認証するために使用されるすべての証明書をクロスチェックの問題について説明します。これは重要なセキュリティ上のステップです。
It is reasonable for the server to insist that the data connection uses a TLS cached session. This might be a cache of a previous data connection or of a cleared control connection. If this is the reason for the refusal to allow the data transfer, then the '522' reply should indicate this.
サーバはデータ接続がTLSキャッシュされたセッションを使用していることを主張することは妥当です。これは、以前のデータ接続のまたはクリア制御接続のキャッシュかもしれません。これは、データ転送を可能にするために拒否の理由がある場合には、「522」の返信はこのことを示す必要があります。
Note: This has an important impact on client design, but allows servers to minimise the cycles used during TLS negotiation by refusing to perform a full negotiation with a previously authenticated client.
注意：これは、クライアントの設計に重要な影響を持っていますが、サーバが以前に認証されたクライアントとの完全な交渉を行うために拒否することによって、TLSネゴシエーション中に使用されるサイクルを最小限に抑えることができます。
It should be noted that the TLS authentication of the server will be authentication of the server host itself and not a user on the server host.
サーバーのTLS認証は、サーバのホスト自体ではなく、サーバーのホスト上のユーザの認証になることに留意すべきです。
In most cases, it is likely that the client will be using TLS because the server would refuse to interact insecurely. To allow for this, clients SHOULD be flexible enough to manage the securing of a session at the appropriate time and still allow the user/server policies to dictate exactly when during the session the security is negotiated.
サーバが安全でない対話を拒否することになるため、ほとんどのケースでは、クライアントがTLSを使用される可能性があります。これを可能にするため、クライアントは適切な時にセッションの確保を管理し、まだセッション中にセキュリティがネゴシエートされたときに、ユーザ/サーバ・ポリシーが正確に指示するように十分に柔軟であるべきです。
In the case where it is the client that is insisting on the securing of the session, the client will need to ensure that the negotiations are all completed satisfactorily and will need to be able to sensibly inform the user should the server not support, or not be prepared to use, the required security levels.
それはセッションの確保を主張しているクライアントである場合には、クライアントは交渉が全て満足に完了し、サーバーがサポートしていなければならない賢明をユーザーに通知することができるようにする必要があります、またはではないことを確認する必要があります、必要なセキュリティレベルを使用するように調製すること。
Clients SHOULD be coded in such a manner as to allow the timing of the AUTH, PBSZ, and PROT commands to be flexible and dictated by the server. It is quite reasonable for a server to refuse certain commands prior to these commands. Similarly, it is quite possible that a SITE or quoted command might be needed by a server prior to the AUTH. A client MUST allow a user to override the timing of these commands to suit a specific server.
AUTH、PBSZのタイミングを可能にするように、クライアントは、そのような方法で符号化されるべきであり、及びPROTは、柔軟で、サーバによって指示されるコマンド。サーバーは、これらのコマンドの前に特定のコマンドを拒否することは非常に合理的です。同様に、サイトまたは引用されたコマンドはAUTHに先立って、サーバが必要とするかもしれないという、かなり可能です。クライアントは、ユーザーが特定のサーバーに合うように、これらのコマンドのタイミングを上書きすることを可能にしなければなりません。
For example, a client SHOULD NOT insist on sending the AUTH as the first command in a session, nor should it insist on issuing a PBSZ/PROT pair directly after the AUTH. This may well be the default behaviour, but must be overridable by a user.
例えば、クライアントは、セッションの最初のコマンドとしてAUTHを送ることを主張すべきではない、またそれはAUTH直後にPBSZ / PROTのペアを発行することを主張すべきです。これがうまくデフォルトの動作かもしれませんが、ユーザーによってオーバーライドでなければなりません。
The TLS negotiation may not be completed satisfactorily for the client, in which case it will be in one of these states:
TLSネゴシエーションが、それはこれらのいずれかの状態になり、その場合には、クライアントの満足に完了しない場合があります。
The TLS negotiation failed completely
TLS交渉が完全に失敗しました
In this case, the control connection should still be in an unprotected mode and the client should issue an unprotected QUIT command to end the session.
この場合、制御接続は、まだ保護されていないモードにする必要がありますし、クライアントがセッションを終了するには、保護されていないQUITコマンドを発行する必要があります。
The TLS negotiation completed successfully, but the client decides that the session parameters are not acceptable (e.g., Distinguished Name in certificate is not the actual server expected).
TLSネゴシエーションが正常に完了しましたが、クライアントは、セッションパラメータが（例えば、証明書の識別名が予想実際のサーバーではありません）許容できないと判断しました。
In this case, the control connection should still be up in a protected state, so the client should issue a protected QUIT command to end the session.
クライアントが保護されたセッションを終了するQUITコマンドを発行する必要がありますので、この場合は、コントロール接続はまだ、保護された状態で起動する必要があります。
The TLS negotiation failed during the TLS handshake.
TLS交渉はTLSハンドシェイク中に失敗しました。
In this case, the control connection is in an unknown state and the client should simply drop the control connection.
この場合、制御接続が不明な状態にあり、クライアントは単にコントロール接続をドロップする必要があります。
Client security policies
クライアントのセキュリティポリシー
Clients do not typically have 'policies' as such, instead they rely on the user to define their actions and, to a certain extent, are reactive to the server policy. Thus, a client will need to have commands that will allow the user to switch the protection level of the data connection dynamically; however, there may be a general 'policy' that attempts all LIST and NLST commands on a Clear connection first (and automatically switches to Private if it fails). In this case, there would need to be a user command available to ensure that a given data transfer was not attempted on an insecure data connection.
クライアントは一般的に、のような「政策」を持たない代わりに、彼らは彼らの行動を定義するために、ユーザーに依存していると、ある程度、サーバ・ポリシーに反応性です。したがって、クライアントは、ユーザーが動的データ接続の保護レベルを切り替えることができますコマンドを持っている必要があります。しかし、すべてのリストを試み、NLSTは、最初のクリア接続でコマンド（と、自動的にそれが失敗した場合にプライベートに切り替わります）一般的な「政策」があるかもしれません。この場合、与えられたデータ転送が安全でないデータ接続で試行されていないことを保証するために利用可能なユーザーコマンドがあることが必要となります。
Clients also need to understand that the level of the PROT setting is only checked for a particular data transfer after that transfer has been requested. Thus, a refusal by the server to accept a particular data transfer should not be read by the client as a refusal to accept that data protection level completely, as not only may other data transfers be acceptable at that protection level, but it is entirely possible that the same transfer may be accepted at the same protection level at a later point in the session.
また、クライアントはその転送が要求された後PROT設定のレベルは、特定のデータ転送のためにのみチェックされていることを理解する必要があります。他のデータ転送は、その保護レベルで許容できるが、それは完全に可能であるだけでなくとしてしたがって、特定のデータ転送を受け入れるためにサーバによって拒否は、完全にそのデータの保護レベルを受け入れるように拒否としてクライアントによって読み取られるべきではありません同じ転送セッションにおける後の時点で同じ保護レベルで受け入れられるかもしれません。
It should be noted that the TLS authentication of the client should be an authentication of a user on the client host and not the client host itself.
クライアントのTLS認証は、クライアントホスト上のユーザーではなく、クライアントのホスト自体の認証であるべきことに留意すべきです。
Client issues 'AUTH TLS', server accepts or rejects. If the server needs AUTH, then it refuses to accept certain commands until it gets a successfully protected session.
クライアントの問題「AUTH TLS」、サーバが受け入れるか拒否します。サーバはAUTHを必要とする場合、それは、それが正常に保護されたセッションを取得するまで、特定のコマンドを受け入れることを拒否します。
Decided entirely by the TLS CipherSuite negotiation.
TLSのCipherSuite交渉によって完全に決定しました。
Client issues PROT command, server accepts or rejects.
クライアントは、サーバが受け入れるか拒否し、PROTコマンドを発行します。
A client would have already issued a PROT command if it required the connection to be protected.
それは保護されるべき接続を必要に応じてクライアントがすでにPROTコマンドを発行しているだろう。
If a server needs to have the connection protected, then it will reply to the STOR/RETR/NLST/... command with a '522', indicating that the current state of the data connection protection level is not sufficient for that data transfer at that time.
サーバが接続を保護している必要がある場合、それはデータ接続保護レベルの現在の状態がそのデータ転送のために十分ではないことを示し、「522」でSTOR / RETR / NLST / ...コマンドに応答します当時。
11.5. What level of protection is required for a particular data transfer?
11.5. 保護のどのレベルは、特定のデータ転送のために必要ですか？
Decided entirely by the TLS CipherSuite negotiation.
TLSのCipherSuite交渉によって完全に決定しました。
Thus, for flexibility, it can be seen that it is desirable for the FTP application to be able to interact with the TLS layer upon which it sits to define and discover the exact TLS CipherSuites that are to be/have been negotiated and to make decisions accordingly.
このように、柔軟性のためには、FTPアプリケーションが、それは/が交渉されていることをして意思決定を行うためにある正確なTLS暗号群を定義し、発見するために座っている時にTLS層と対話できるようにすることが望ましいことがわかりますそれに応じて。
These timing diagrams aim to help explain exactly how the TLS handshake and session protection fits into the existing logic of the FTP protocol. Of course, the FTP protocol itself is not well described with respect to the timing of commands and responses in [RFC-959], so this is partly based on empirical observation of existing widespread client and server implementations.
これらのタイミング図は、TLSハンドシェイクとセッション保護がFTPプロトコルの既存のロジックに収まる正確にどのように説明するのに役立つことを目指しています。もちろん、FTPプロトコル自体は良く[RFC-959]でコマンドと応答のタイミングに関して説明されていないので、これは部分的に、既存の普及、クライアントとサーバの実装の経験的観察に基づいています。
Client Server
control data data control
====================================================================
socket()
bind()
socket()
connect() ----------------------------------------------> accept()
<---------------------------------------------- 220
AUTH TLS ---------------------------------------------->
<---------------------------------------------- 234
TLSneg() <----------------------------------------------> TLSneg()
PBSZ 0 ---------------------------------------------->
<---------------------------------------------- 200
PROT P ---------------------------------------------->
<---------------------------------------------- 200
USER fred ---------------------------------------------->
<---------------------------------------------- 331
PASS pass ---------------------------------------------->
<---------------------------------------------- 230
Note 1: The order of the PBSZ/PROT pair and the USER/PASS pair (with respect to each other) is not important (i.e., the USER/PASS can happen prior to the PBSZ/PROT, or the server can refuse to allow a PBSZ/PROT pair until the USER/PASS pair has happened).
注1：（互いに対して）PBSZ / PROT対とUSER / PASSペアの順序（すなわち、USER / PASS前PBSZ / PROTに起こることができ、またはサーバが許可を拒否することができる重要ではありませんUSER / PASSペアまでPBSZ / PROTのペア）が起こっています。
Note 2: The PASS command might not be required at all (if the USER parameter and any client identity presented provide sufficient authentication). The server would indicate this by issuing a '232' reply to the USER command instead of the '331', which requests a PASS from the client (see below).
注2：（USERパラメータと提示したクライアントIDが十分な認証を提供する場合）PASSコマンドが全く必要とされない場合があります。サーバは、（下記参照）の代わりに、クライアントからのパスを要求「331」、のUSERコマンドに「232」の応答を発行することによって、これを示すことになります。
Note 3: The AUTH command might not be the first command after the receipt of the 220 welcome message.
注3：AUTHコマンドは、220のウェルカムメッセージを受信した後、最初のコマンドではないかもしれません。
12.2. Establishing a Protected Session Without a Password Request (The TLS Authentication is Sufficient)
12.2. パスワードの要求なしに保護されたセッションの確立（TLS認証で十分です）
Client Server
control data data control
====================================================================
socket()
bind()
socket()
connect() ----------------------------------------------> accept()
<---------------------------------------------- 220
AUTH TLS ---------------------------------------------->
<---------------------------------------------- 234
TLSneg() <----------------------------------------------> TLSneg()
PBSZ 0 ---------------------------------------------->
<---------------------------------------------- 200
PROT P ---------------------------------------------->
<---------------------------------------------- 200
USER fred ---------------------------------------------->
<---------------------------------------------- 232
12.3. Establishing a Protected Session and then Clearing with the CCC Command
12.3. 保護されたセッションを確立し、その後、CCCコマンドでクリア
Client Server
control data data control
====================================================================
socket()
bind()
socket()
connect() ----------------------------------------------> accept()
<---------------------------------------------- 220
AUTH TLS ---------------------------------------------->
<---------------------------------------------- 234
TLSneg() <----------------------------------------------> TLSneg()
PBSZ 0 ---------------------------------------------->
<---------------------------------------------- 200
PROT P ---------------------------------------------->
<---------------------------------------------- 200
USER fred ---------------------------------------------->
<---------------------------------------------- 232
CCC ---------------------------------------------->
<---------------------------------------------- 200
TLSshutdown() <-------------------------------------> TLSshutdown()
- The rest of the control session continues in plaintext with protected data transfers (due to PROT P).
- コントロール・セッションの残りの部分は、（原因PROT Pに）保護されたデータ転送に平文で継続します。
Note: This has serious security issues (see Security Considerations section) but may be useful in a firewall/NAT scenario.
注：これは深刻なセキュリティ上の問題があります（セキュリティの考慮事項のセクションを参照）が、ファイアウォール/ NATのシナリオにおいても有用であり得ます。
Client Server
control data data control
====================================================================
socket()
bind()
PORT w,x,y,z,a,b ----------------------------------------->
<----------------------------------------------------- 200
STOR file ------------------------------------------------>
socket()
bind()
<----------------------------------------------------- 150
accept() <----------- connect()
write() -----------> read()
close() -----------> close()
<----------------------------------------------------- 226
Client Server
control data data control
====================================================================
PASV -------------------------------------------------------->
socket()
bind()
<------------------------------------------ 227 (w,x,y,z,a,b)
socket()
STOR file --------------------------------------------------->
connect() ----------> accept()
<-------------------------------------------------------- 150
write() ----------> read()
close() ----------> close()
<-------------------------------------------------------- 226
Note: Implementers should be aware that the connect()/accept() function is performed prior to the receipt of the reply from the STOR command. This contrasts the with situation when a non-firewall-friendly PORT is used prior to the STOR, and the accept()/connect() is performed after the reply from the aforementioned STOR has been dealt with.
注：実装者は、CONNECT（）/受け入れる（）関数が前STORコマンドからの応答の受信に行われることを認識すべきです。これは、非ファイアウォールフレンドリーPORTが前STORに使用されたときの状況とは対照的で、そして受け入れ（）/ connect（）を前述のSTORからの返信が取り扱われた後に行われます。
Client Server
control data data control
====================================================================
socket()
bind()
PORT w,x,y,z,a,b -------------------------------------------->
<-------------------------------------------------------- 200
STOR file --------------------------------------------------->
socket()
bind()
<-------------------------------------------------------- 150
accept() <---------- connect()
TLSneg() <----------> TLSneg()
TLSwrite() ----------> TLSread()
TLSshutdown() -------> TLSshutdown()
close() ----------> close()
<-------------------------------------------------------- 226
Client Server
control data data control
====================================================================
PASV -------------------------------------------------------->
socket()
bind()
<------------------------------------------ 227 (w,x,y,z,a,b)
socket()
STOR file --------------------------------------------------->
connect() ----------> accept()
<-------------------------------------------------------- 150
TLSneg() <---------> TLSneg()
TLSwrite() ---------> TLSread()
TLSshutdown() -------> TLSshutdown()
close() ---------> close()
<-------------------------------------------------------- 226
The REIN command, defined in [RFC-959], allows the user to reset the state of the FTP session. From [RFC-959]:
[RFC-959]で定義されたREINコマンドは、ユーザがFTPセッションの状態をリセットすることを可能にします。 [RFC-959]から：
REINITIALIZE (REIN)
REINITIALIZE（REIN）
This command terminates a USER, flushing all I/O and account information, except to allow any transfer in progress to be completed. All parameters are reset to the default settings and the control connection is left open. This is identical to the state in which a user finds himself immediately after the control connection is opened. A USER command may be expected to follow.
このコマンドは、すべてのI / Oをフラッシュ、USERを終了し、アカウント情報を、進行中の転送が完了できるようにすることを除いて。すべてのパラメータは、デフォルトの設定にリセットされ、制御接続が開いたままにされます。これは、制御接続が開かれた後、ユーザーはすぐに自分自身を発見している状態と同じです。 USERコマンドが続くことが予想されます。
When this command is processed by the server, the TLS session(s) MUST be cleared and the control and data connections revert to unprotected, clear communications. It MAY be acceptable to use cached TLS sessions for subsequent connections, however, a server MUST NOT mandate this.
このコマンドは、サーバによって処理されるとき、TLSセッション（複数可）をクリアしなければならなくて、コントロール及びデータ接続は保護されていない、明確な通信に戻します。それは、後続の接続のためにキャッシュされたTLSセッションを使用して許容することができるが、サーバーはこれを強制してはなりません。
If the REIN command is being used to clear a TLS session, then the reply to the REIN command MUST be sent in a protected session prior to the session(s) being cleared.
REINコマンドは、TLSセッションをクリアするために使用されている場合、REINコマンドに対する応答がクリアされる（複数の）前のセッションに保護されたセッションで送信されなければなりません。
The ABOR and STAT commands and the use of TCP Urgent Pointers
ABORとSTATコマンドやTCP緊急ポインタの使用
[RFC-959] describes the use of Telnet commands (IP and DM) and the TCP Urgent pointer to indicate the transmission of commands on the control channel during the execution of a data transfer. FTP uses the Telnet Interrupt Process and Data Mark commands in conjunction with Urgent data to preface two commands: ABOR (Abort Transfer) and STAT (Status request).
[RFC-959]（IP及びDM）のTelnetを使用するコマンドについて説明し、TCP緊急ポインタは、データ転送の実行中に制御チャネル上のコマンドの送信を指示します。 FTPは、Telnet割り込み処理を使用し、データマークが2つのコマンドを前置きする緊急データと一緒にコマンド：ABOR（転送を中止）およびSTAT（ステータス要求）。
The Urgent Pointer was used because, in a Unix implementation, the receipt of a TCP packet marked as Urgent would result in the execution of the SIGURG interrupt handler. This reliance on interrupt handlers was necessary on systems that did not implement select() or did not support multiple threads. TLS does not support the notion of Urgent data.
Unixの実装では、緊急としてマークされたTCPパケットの受信がSIGURG割り込みハンドラの実行につながる、ため、緊急ポインタを使用しました。割り込みハンドラにこの依存は（選択実装していない）、または複数のスレッドをサポートしていませんでしたシステム上で必要がありました。 TLSは、緊急データの概念をサポートしていません。
When TLS is implemented as a security method in FTP, the server SHOULD NOT rely on the use of SIGURG to process input on the control channel during data transfers. The client MUST send all data, including Telnet commands, across the TLS session.
TLSは、FTPのセキュリティメソッドとして実装されている場合、サーバは、データ転送中に制御チャネル上の入力を処理するためにSIGURGの使用に依存すべきではありません。クライアントがTLSセッション間で、telnetコマンドを含むすべてのデータを、送らなければなりません。
This document discusses how TLS may be used in conjunction with [RFC-2228] to provide mechanisms for securing FTP sessions. Discussions about security rationale and security properties are contained within the [RFC-2228] document and are not repeated here.
この文書では、TLSは、FTPセッションを確保するためのメカニズムを提供するために、[RFC-2228]と組み合わせて使用することができる方法について説明します。セキュリティの根拠とセキュリティの特性についての議論は[RFC-2228]文書に含まれており、ここでは繰り返しません。
In this section, we assume that X.509 certificates will be used for the TLS authentication. If some other identity token is used (e.g., kerberos tickets - see [RFC-2712]), then similar, mechanism-specific considerations will need to be made.
このセクションでは、X.509証明書は、TLS認証のために使用されることを前提としています。いくつかの他のアイデンティティ・トークンを（例えば、ケルベロスチケット - [RFC-2712]を参照）を使用する場合には、同様の、機構固有の考慮がなされる必要があります。
- Although it is entirely an implementation decision, it is recommended that certificates used for server authentication of the TLS session contain the server identification information in a similar manner to those used for http servers (see [RFC-2818]).
- それは完全に実装決定であるが、それはTLSセッションのサーバ認証に使用する証明書は、HTTPサーバに使用されるものと同様に、サーバ識別情報を含むことが推奨されている（参照[RFC-2818]）。
- It is strongly recommended that the certificate used for server authentication of Data connections be the same certificate as that used for the corresponding Control connection. If different certificates are to be used, there should be some other mechanism that the client can use to cross-check the data and control connection server identities.
- 強く、データ接続のサーバー認証に使用する証明書は、対応するコントロールの接続に用いられるものと同じ証明書にすることをお勧めします。異なる証明書を使用する場合、クライアントは、クロスチェックデータおよび制御接続サーバIDに使用できるいくつかの他のメカニズムがあるはずです。
- If Server Certificates are not used, then many of the security benefits will not be realised. For Example, in an anonymous Diffie-Hellman environment, there is no server identity authentication, so there is little protection against man-in-the-middle attacks.
- サーバ証明書を使用しない場合は、セキュリティ上の利点の多くが実現されることはありません。例えば、匿名のDiffie-Hellman環境で、どのサーバーのID認証が存在しないので、man-in-the-middle攻撃に対してはほとんど保護があります。
- Deciding which client certificates to allow and defining which fields define what authentication information is entirely a server implementation issue.
- 完全にサーバーの実装の問題が何であるかを認証情報を定義フィールドを許可し、定義するためにどのクライアント証明書を決定。
- However, it is strongly recommended that the certificate used for client authentication of Data connections be the same certificate as that used for the corresponding Control connection. If different certificates are to be used, there should be some other mechanism that the server can use to cross-check the data and control connection client identities.
- しかし、データ接続のクライアント認証に使用する証明書は、対応する制御接続に用いられるものと同じ証明書であることを強くお勧めします。異なる証明書を使用する場合、サーバはクロスチェックデータおよび制御接続クライアントのアイデンティティに使用することができますいくつかの他のメカニズムがあるはずです。
- If Client Certificates are not used, then many of the security benefits will not be realised. For Example, it would still be possible for a malicious client to hijack a data connection.
- クライアント証明書が使用されていない場合は、セキュリティ上の利点の多くが実現されることはありません。悪意のあるクライアントがデータ接続をハイジャックするために例えば、それはまだ可能です。
A bounce attack should be harder in a secured FTP environment because:
バウンス攻撃は、セキュアなFTP環境ために難しくする必要があります：
- The FTP server that is being used to initiate a false connection will always be a 'server' in the TLS context. Therefore, only services that act as 'clients' in the TLS context could be vulnerable. This would be a counter-intuitive way to implement TLS on a service.
- 偽の接続を開始するために使用されているFTPサーバは常にTLSコンテキスト内の「サーバ」になります。したがって、TLSコンテキストで「クライアント」として動作する唯一のサービスは、脆弱である可能性があります。これは、サービス上でTLSを実装するための直感的方法だろう。
- The FTP server would detect that the authentication credentials for the data connection are not the same as those for the control connection, thus the server policies could be set to drop the data connection.
- FTPサーバはデータ接続のための認証証明書は、このように、サーバーのポリシーがデータ接続をドロップするように設定することができ、制御接続のためのものと同じではないことを検出するであろう。
- Genuine users are less likely to initiate such attacks when the authentication is strong, and malicious users are less likely to gain access to the FTP server if the authentication is not easily subverted (password guessing, network tracing, etc...)
- 本物のユーザは、認証が強い場合、このような攻撃を開始する可能性が低いと、悪意のあるユーザーは、認証が簡単に覆されていない場合は、FTPサーバーへのアクセスを獲得する可能性が低い（パスワードは、ネットワークトレース、推測など...）
This document presents a strong mechanism for solving the issue raised in this section.
この文書では、このセクションで提起された問題を解決するための強力なメカニズムを提供します。
The twin solutions of strong authentication and data confidentiality ensure that this is not an issue when TLS is used to protect the control session.
強力な認証とデータの機密性の双子のソリューションは、TLSは、制御セッションを保護するために使用されるとき、これは問題ではないことを確認してください。
The TLS protocol ensures data confidentiality by encryption. Privacy (e.g., access to download logs, user profile information, etc...) is outside the scope of this document (and [RFC-2577] presumably).
TLSプロトコルは、暗号化することにより、データの機密性を保証します。プライバシー（ログ、ユーザプロファイル情報などをダウンロードするために、例えば、アクセス...）（おそらくと[RFC-2577]）は、この文書の範囲外です。
This is not an issue when TLS is used as the primary authentication mechanism.
これは、TLSは、プライマリ認証メカニズムとして使用されている問題ではありません。
This specification will do little for the Denial of Service element of this section; however, strong authentication on the data connection will prevent unauthorised connections from retrieving or submitting files. Of course, this is only the case where strong client authentication is being used. If client certificates are not used, then port stealing by a rogue client is still a problem. If no strong authentication is in use at all (e.g., anonymous Diffie-Hellman), then the port stealing problem will remain.
この仕様は、このセクションのサービス拒否の要素のために少しを行います。ただし、データ接続の強力な認証を取得したり、ファイルを提出からの不正接続を防止します。もちろん、これは強力なクライアント認証が使用されている場合のみです。クライアント証明書が使用されていない場合は、不正なクライアントによって盗み、ポートはまだ問題があります。強い認証はすべて（例えば、匿名のDiffie-Hellmanの）で使用されていない場合は、問題を盗むポートが残ります。
Nothing in this specification will affect the discussion in this section.
この仕様では何もこの節での議論に影響を与えません。
Using the CCC command can create security issues. For a full description, see the "CLEAR COMMAND CHANNEL (CCC)" section of [RFC-2228]. Clients should not assume that a server will allow the CCC command to be processed.
CCCコマンドを使用すると、セキュリティ上の問題を作成することができます。詳細については、[RFC-2228]の "CLEAR COMMAND CHANNEL（CCC）" を参照してください。クライアントは、サーバがCCCコマンドを処理することができるようになると仮定するべきではありません。
Server implementations may wish to refuse to process the CCC command on a session that has not passed through some form of client authentication (e.g., TLS client auth or FTP USER/PASS). This can prevent anonymous clients from repeatedly requesting AUTH TLS followed by CCC to tie up resources on the server.
サーバ実装は、クライアント認証のいくつかの形式（例えば、TLSクライアント認証またはFTP USER / PASS）を通過していないセッションにCCCコマンドを処理することを拒否することもできます。これは繰り返し、サーバー上のリソースをタイアップするCCCが続いたAUTH TLSを要求するから匿名クライアントを防ぐことができます。
{FTP-PORT} - The port assigned to the FTP control connection is 21.
{FTP-PORT} - FTP制御接続に割り当てられたポート21です。
{TLS-PARM} - The parameter for the AUTH command to indicate that TLS is required. To request the TLS protocol in accordance with this document, the client MUST use 'TLS'
{TLS-PARM} - AUTHコマンドのパラメータは、TLSが必要であることを示します。この文書に基づいてTLSプロトコルを要求するには、クライアントが「TLS」を使用しなければなりません
To maintain backward compatibility with older versions of this document, the server SHOULD accept 'TLS-C' as a synonym for 'TLS'.
このドキュメントの旧バージョンとの下位互換性を維持するために、サーバは、「TLS」の同義語として「TLS-C」を受け入れる必要があります。
Note: [RFC-2228] states that these parameters are case-insensitive.
注意：[RFC-2228]は、これらのパラメータは大文字と小文字を区別しないと述べています。
There are no issues other than those concerned with the ability of the server to refuse to have a complete TLS negotiation for each and every data connection, which will allow servers to retain throughput whilst using cycles only when necessary.
サーバは、必要な場合にのみサイクルを使用しながら、スループットを維持することができますそれぞれすべてのデータ接続のための完全なTLSネゴシエーションを、持っていることを拒否するために、サーバーの能力に関係している以外の問題はありません。
This mechanism is generally applicable as a mechanism for securing the FTP protocol. It is unlikely that anonymous FTP clients or servers will require such security (although some might like the authentication features without the confidentiality).
このメカニズムは、FTPプロトコルを確保するための機構として一般的に適用可能です。 （いくつかは、機密性のない認証機能を好むかもしれませんが）匿名FTPクライアントまたはサーバは、このようなセキュリティを必要とすることはほとんどありません。
o Netscape Communications Corporation for the original SSL protocol.
オリジナルのSSLプロトコル用のNetscape Communications Corporation社は、O。
o Eric Young for the SSLeay libraries.
SSLeayのライブラリ用のO Eric Young氏。
o University of California, Berkeley for the original implementations of FTP and ftpd, on which the initial implementation of these extensions were layered.
これらの拡張機能の最初の実装は、階層化された上でFTPとFTPDのオリジナルの実装のためのOカリフォルニア大学バークレー校。
o IETF CAT working group.
IETF CATワーキンググループO。
o IETF TLS working group.
IETF TLSワーキンググループO。
o IETF FTPEXT working group.
IETFワーキンググループFTPEXT O。
o Jeff Altman for the ABOR and STAT discussion.
ABORとSTAT議論のためのOジェフアルトマン。
o The various people who have help author this document throughout its protracted draft stages, namely Martin Carpenter, Eric Murray, Tim Hudson, and Volker Wiegand.
その長引くドラフトの段階、すなわちマーティン・カーペンター、エリック・マレー、ティム・ハドソン、およびフォルカー・ウィーガンドを通して作者この文書を助けを持っている様々な人々が、O。
[RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC-959]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC-2228] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228, October 1997.
[RFC-2228]ホロヴィッツ、M.とS.ラント、 "FTPセキュリティ拡張機能"、RFC 2228、1997年10月。
[RFC-2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC-2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC-2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998.
[RFC-2389] Hethmon、P.とR.エルツ、 "ファイル転送プロトコルの機能ネゴシエーションメカニズム"、RFC 2389、1998年8月。
[RFC-1579] Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February 1994.
[RFC-1579] Bellovin氏、S.、 "ファイアウォールフレンドリーFTP"、RFC 1579、1994年2月。
[RFC-2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC-2222]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。
[RFC-2577] Allman, M. and S. Ostermann, "FTP Security Considerations", RFC 2577, May 1999.
[RFC-2577]オールマン、M.とS. Ostermann、 "FTPセキュリティに関する考慮事項"、RFC 2577、1999年5月。
[RFC-2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.
[RFC-2712] Medvinsky、A.とM.ハー、 "Layer Security（TLS）を輸送するためのケルベロス暗号スイートの追加"、RFC 2712、1999年10月。
[RFC-2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC-2817] Khare、R.およびS.ローレンス、 "HTTP / 1.1内でTLSへのアップグレード"、RFC 2817、2000年5月。
[RFC-2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC-2818]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。
[RFC-3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC-3207]、RFC 3207、2002年2月ホフマン、P.、 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"。
Contributors
協力者
Tim Hudson RSA Data Security Australia Pty Ltd
ティム・ハドソンRSAデータセキュリティオーストラリアPty Ltdの
Phone: +61 7 3227 4444 EMail: tjh@rsasecurity.com.au
電話：+61 7 3227 4444 Eメール：tjh@rsasecurity.com.au
Volker Wiegand SuSE Linux
フォルカー・ウィーガンドSUSE LINUX
EMail: wiegand@suse.de
メールアドレス：wiegand@suse.de
Martin Carpenter Verisign Ltd
マーティン・カーペンターベリサイン株式会社
EMail: mcarpenter@verisign.com
メールアドレス：mcarpenter@verisign.com
Eric Murray Wave Systems Inc.
エリック・マレーウェーブシステムズ株式会社
EMail: ericm@lne.com
メールアドレス：ericm@lne.com
Author's Address
著者のアドレス
Paul Ford-Hutchinson IBM UK Ltd PO Box 31 Birmingham Road Warwick United Kingdom
ポール・フォード・ハッチンソンIBMのイギリス株式会社私書箱31バーミンガムロードワーウィックイギリス
Phone: +44 1926 462005 EMail: rfc4217@ford-hutchinson.com
電話：+44 1926 462005 Eメール：rfc4217@ford-hutchinson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。