[要約] RFC 4217は、FTPをTLSでセキュアにするためのプロトコル仕様です。その目的は、FTPセッションの暗号化と認証を提供し、データの安全性を確保することです。
Network Working Group P. Ford-Hutchinson
Request for Comments: 4217 IBM UK Ltd
Category: Standards Track October 2005
Securing FTP with TLS
TLSでFTPを保護します
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).
Copyright（c）The Internet Society（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プロトコルバージョン1.0」で定義されたTLSプロトコルを使用してセキュリティと認証を実装するためにFTPクライアントとサーバーが使用できるメカニズムについて説明します。FTPセキュリティ拡張機能」。必要な拡張機能のサブセットと使用するパラメーターについて説明し、クライアントとサーバーがとる必要のあるポリシーの問題のいくつかを議論し、それらのポリシーの意味の一部を考慮し、実装の予想される行動を許可するためのいくつかの予想される行動について説明します。相互操作。このドキュメントは、RFC 2487のSMTPに提供されたものと同様の方法でFTPのTLSサポート、「輸送層セキュリティの安全なSMTPのSMTPサービス拡張」、RFC 2817のHTTP、HTTP/1.1内の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:
このドキュメントでは、他の3つのドキュメントを組み合わせて、有用で相互運用可能で安全なファイル転送プロトコルを提供する方法について説明します。これらのドキュメントは次のとおりです。
RFC 959 [RFC-959]
RFC 959 [RFC-959]
The description of the Internet File Transfer Protocol.
インターネットファイル転送プロトコルの説明。
RFC 2246 [RFC-2246]
RFC2246 [RFC-2246]
The description of the Transport Layer Security protocol (developed from the Netscape Secure Sockets Layer (SSL) protocol version 3.0).
トランスポートレイヤーセキュリティプロトコルの説明（Netscape Secure Socketsレイヤー（SSL）プロトコルバージョン3.0から開発）。
RFC 2228 [RFC-2228]
RFC2228 [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 3207 [RFC-3207]のSMTPおよびRFC 2817 [RFC-2817]のHTTPに提供された方法と同様の方法で、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.
- 正式な公開キー管理。認証フェーズ中に確立されたクライアントIDメカニズム（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 Communication CorporationのSSLプロトコルの開発であり、このドキュメントを使用して、FTPプロトコルをSSLまたはTLSのいずれかで使用できるようにすることができます。使用される実際のプロトコルは、TLS/SSLレイヤーによる保護セッションの交渉によって決定されます。このドキュメントは、TLSプロトコルのみを参照します。ただし、クライアントとサーバーが実際にSSLがそのように構成されている場合、実際に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].
「必須」、「必要」、「必須」、「shall」、「shall "、" obly "、" should "、" nove "、" becommended "、" optional "は、このドキュメントに表示されます。[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}に耳を傾け、セッションの開始はまったく保護されていません。クライアントがセッションの保護を希望すると、認証コマンドが送信され、サーバーが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'）を要求するパラメーターを使用して認証コマンドを送信する必要があります。
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交渉の結果に応じて、そのポリシーに従って動作する必要があります。認証拒否を受けたクライアントは、それが望むなら、セッションを保護されていないことを選択することができます。
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.
[RFC-2228]で定義されている「334」応答は、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プロトコルは、ユーザーコマンドを使用して、FTPサーバーを使用しようとするエンティティを識別することを主張します。TLS交渉は認証情報を提供している可能性がありますが、ユーザーコマンドは引き続きクライアントが発行する必要があります。ただし、使用するクライアント証明書とユーザーコマンドのパラメーターとの間で行うための一貫性チェックを決定するのは、サーバー実装の問題です。
[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コマンドに従って、ユーザーがユーザーの一部またはすべてを再発行、渡す、およびACCTコマンドを再発行する必要があると述べています。さらに、このドキュメントは、まるでReinコマンドが発行されたかのように、他のすべての転送パラメーター（AUTHパラメーター以外）をリセットする必要があることを指定しています。
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.
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.
通常、認証、ユーザー、パス、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.
featコマンド（[RFC-2389]で導入）により、追加機能を備えたサーバーは、featコマンドに応答してクライアントにこれらを宣伝することができます。サーバーがFeatコマンドをサポートする場合、[RFC-2389]のセクション3.2で説明されているように、返信にサポートされたAUTH、PBSZ、およびPROTコマンドを宣伝する必要があります。さらに、authコマンドには、「tls」を認証する可能性のあるパラメーターの1つとして識別する返信が必要です。「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-extensionsサポート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つの方法のいずれかで使用できます。（注：これらの説明は必ずしも正確な年代順に配置されているわけではありませんが、必要な手順を説明してください。明確化については後で図を参照してください。）
i) Classic FTP client/server data exchange
i) 古典的な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.
ii）PASVコマンドを使用して、ファイアウォールに優しいクライアント/サーバーデータ交換（[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.
- クライアントは、サーバーAがポートを開くことを要求します。サーバーAはポートを取得し、クライアントに返します。クライアントはこのポート番号をサーバーBに送信します。サーバーBはサーバーAに接続します。クライアントはサーバーAに送信または受信リクエストを送信し、サーバーBへの補完とデータ転送が開始されます。このモデルでは、サーバーAはプロキシまたはPASVホストであり、サーバー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].
つまり、Connect（）呼び出しとの接続を開始するか、どの側がAccept（）コールを介して接続に反応するかは関係ありません。[RFC-959]で定義されているFTPクライアントは、[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）では、FTPサーバーがファイアウォールに優しいFTP [RFC-1579]のTLSサーバーとして機能しなければならないという事実を考えると、サーバーAもサーバーBも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をネゴシエートすることができます。データチャネルも保護するには、PSBZコマンドを使用してPROTコマンドシーケンスを使用する必要があります。
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コマンドを発行するクライアントによって変更される場合があります。このデータチャネル保護交渉は、セッションの任意の時点（ポートまたは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.
[RFC-2228]で指定されているProTコマンドは、データ接続のセキュリティレベルのクライアント/サーバーの交渉を許可します。クライアントによってPROTコマンドが発行され、「200」の返信を返すサーバーによって受け入れられると、他のProTコマンドが発行され、受け入れられるまで、後続のデータ接続のセキュリティがそのレベルにある必要があります。セッションが終了し、Rein Commandが発行されるか、セッションのセキュリティ（認証コマンドを介して）が再交渉されます。
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) CLEAR（ '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.
さらに、[RFC-2228]に詳述されているように、PBSZ（保護バッファーサイズ）コマンドは、任意の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がネゴシエートされる前にコマンドを拒否します（ログインする前にサイトまたはそのようなコマンドが必要な場合に問題を引き起こす可能性があります）。
- Deny certain commands before TLS is negotiated (e.g., USER, PASS, or ACCT).
- TLSが交渉する前に特定のコマンドを拒否します（ユーザー、パス、または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).
- 使用される可能性のあるciphersuitesを定義します（おそらく、ホスト/ドメイン/...ベースごとに）。
- 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交渉は、サーバーのために十分に完了しない可能性があります。その場合、これらの状態の1つになる可能性があります。
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」の返信を発行して接続を閉じます。
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.
サーバーは、データ接続の4つの基本ビューのいずれかを取得できます。
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.
サーバーは、データ転送を開始する（ポートまたはPASVではなく）、実際のコマンドのデータ保護レベル（上記のオプション3および4の場合）のステータスのみを確認する必要があります。[RFC-959]で定義されている次のコマンドは、データ接続が開かれ、したがって、誤ったPROT設定のために1XXメッセージの前に拒否される可能性があります。
STOR RETR NLST LIST STOU APPE
Stor Retr NlstリストStou Appe
The reply to indicate that the PROT setting is incorrect is '521 data connection cannot be opened with this PROT setting'
Protの設定が間違っていることを示すための返信は、「このProT設定では521データ接続を開くことができない」
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交渉とは気に入らない場合、すぐにデータポートを閉じて、「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.
セキュリティ上の考慮事項セクションでは、コントロール接続の認証に使用されるデータ接続を認証するために使用される証明書をクロスチェックする問題について説明します。これは重要なセキュリティステップです。
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」、サーバーは受け入れまたは拒否します。サーバーが認証を必要とする場合、正常に保護されたセッションを取得するまで、特定のコマンドを受け入れることを拒否します。
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/...コマンドに返信します。その時。
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ペアとユーザー/パスペアの順序（互いに）は重要ではありません（つまり、PBSZ/PROTの前にユーザー/パスが発生する可能性があります。ユーザー/パスペアが発生するまで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：パスコマンドはまったく必要ない場合があります（ユーザーパラメーターと提示されたクライアントIDが十分な認証を提供する場合）。サーバーは、クライアントからのパスを要求する「331」の代わりにユーザーコマンドへの「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
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（）/accept（）関数がStorコマンドからの返信を受信する前に実行されることに注意する必要があります。これは、ストアの前にファイアウォールに優しいポートを使用していない状況とは対照的であり、前述のStorからの返信が処理された後にAccept（）/Connect（）が実行されます。
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とアカウント情報をフラッシングし、ユーザーを終了します。すべてのパラメーターはデフォルト設定にリセットされ、制御接続が開いたままになります。これは、制御接続が開かれた直後にユーザーが自分自身を見つける状態と同じです。ユーザーコマンドが従うことが期待される場合があります。
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.
TLSセッションをクリアするためにReinコマンドが使用されている場合、セッションがクリアされる前に、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]は、Telnetコマンド（IPおよびDM）とTCP緊急ポインターの使用を説明して、データ転送の実行中にコントロールチャネル上のコマンドの送信を示します。FTPは、Telnet割り込みプロセスとデータマークコマンドを緊急データと併せて、2つのコマンド（Abor（Abort転送）と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 Interructing Handlerの実行につながるため、緊急のポインターが使用されました。中割り込みハンドラーへの依存は、Select（）を実装していない、または複数のスレッドをサポートしなかったシステムで必要でした。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.
このドキュメントでは、FTPセッションを保護するためのメカニズムを提供するために、[RFC-2228]と組み合わせてTLSを使用する方法について説明します。セキュリティの根拠とセキュリティプロパティに関する議論は、[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認証に使用されると仮定します。他のアイデンティティトークンを使用する場合（たとえば、Kerberosチケット - [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.
- データ接続のサーバー認証に使用される証明書は、対応する制御接続に使用されている証明書と同じ証明書であることを強くお勧めします。異なる証明書を使用する場合、クライアントがデータをクロスチェックして接続サーバーのアイデンティティを制御するために使用できる他のメカニズムがあるはずです。
- 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認証がないため、中間の攻撃に対する保護はほとんどありません。
- 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クライアントAUTHまたはFTPユーザー/パスなど）を通過していないセッションでCCCコマンドの処理を拒否する場合があります。これにより、匿名のクライアントがAuth TLSを繰り返し要求することを防ぐことができます。その後、CCCがサーバー上にリソースを結び付けることができます。
{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-C」を「TLS」の同義語として受け入れる必要があります。
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.
o 元のSSLプロトコルのNetscape Communications Corporation。
o Eric Young for the SSLeay libraries.
o SSLEAYライブラリの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.
o カリフォルニア大学バークレー校FTPとFTPDの元の実装のためのバークレー。これらの拡張機能の最初の実装が階層化されました。
o IETF CAT working group.
o IETF CATワーキンググループ。
o IETF TLS working group.
o IETF TLSワーキンググループ。
o IETF FTPEXT working group.
o ietf ftpextワーキンググループ。
o Jeff Altman for the ABOR and STAT discussion.
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] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC-2228] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228, October 1997.
[RFC-2228] Horowitz、M。およびS. Lunt、「FTP Security Extensions」、RFC 2228、1997年10月。
[RFC-2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC-2246] Dierks、T。およびC. Allen、「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. Elz、「ファイル転送プロトコルの特徴交渉メカニズム」、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] Myers、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
[RFC-2577] Allman, M. and S. Ostermann, "FTP Security Considerations", RFC 2577, May 1999.
[RFC-2577] Allman、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. Hur、「層のセキュリティ（TLS）へのKerberos cipherスイートの追加」、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. Lawrence、「HTTP/1.1内のTLSへのアップグレード」、RFC 2817、2000年5月。
[RFC-2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC-2818] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[RFC-3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC-3207] Hoffman、P。、「輸送層セキュリティ上の安全なSMTPのSMTPサービス拡張」、RFC 3207、2002年2月。
Contributors
貢献者
Tim Hudson RSA Data Security Australia Pty Ltd
Tim Hudson RSA Data Security Australia Pty Ltd
Phone: +61 7 3227 4444
EMail: tjh@rsasecurity.com.au
Volker Wiegand SuSE Linux
Volker Wiegand Suse Linux
EMail: wiegand@suse.de
Martin Carpenter Verisign Ltd
Martin Carpenter Verisign Ltd
EMail: mcarpenter@verisign.com
Eric Murray Wave Systems Inc.
Eric Murray Wave Systems Inc.
EMail: ericm@lne.com
Author's Address
著者の連絡先
Paul Ford-Hutchinson IBM UK Ltd PO Box 31 Birmingham Road Warwick United Kingdom
Paul Ford-Hutchinson IBM UK Ltd PO Box 31バーミンガムロードワーウィックイギリス
Phone: +44 1926 462005
EMail: rfc4217@ford-hutchinson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。