RFC4217 日本語訳
4217 Securing FTP with TLS. P. Ford-Hutchinson. October 2005. (Format: TXT=61180 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Ford-Hutchinson Request for Comments: 4217 IBM UK Ltd Category: Standards Track October 2005
コメントを求めるワーキンググループP.フォード-ハッチンソン要求をネットワークでつないでください: 4217年のIBMイギリスのLtdカテゴリ: 標準化過程2005年10月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.".
このドキュメントはFTPクライアントとサーバによって使用される、RFC2246によって定義されたTLSプロトコル、RFC2228、「FTPセキュリティ拡大」で. FTPプロトコルへの拡大が定義した「TLSプロトコルバージョン1.0」を使用することでセキュリティと認証を実装することができるメカニズムについて説明します。 それは、interoperationを許容するために使用されるために必要である拡大とパラメタの部分集合について説明して、クライアントとサーバが取る必要がある政策問題のいくつかについて議論して、それらの方針の含意のいくつかを考えて、実装のいくつかの予想されたふるまいについて議論します。 このドキュメントがRFC2487、「トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子」、およびRFC2817のHTTPでFTPのサポートをSMTPに提供されたそれへの同様の方法でTLSに供給することを意図します、「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".
RFC959、「ファイル転送プロトコル」に従って、この仕様はあります。 RFC2246. 「TLSプロトコルバージョン1.0」RFC2228、「FTPセキュリティ拡大」をそれは当てにします。
Ford-Hutchinson Standards Track [Page 1] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[1ページ]RFC4217
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
1. 序論…3 2. 聴衆…5 3. 概要…5 4. 制御ポートのセッション交渉…5 4.1. クライアントは機密保護しているセッションが欲しいです…5 4.2. サーバは機密保護しているセッションを必要とします…6 5. 制御ポートをきれいにします…6 6. 功績命令への応答…7 7. データ接続のふるまい…8 8. AUTHのためのメカニズムは命令します…9 9. データ接続セキュリティ…9 10. 交渉のふるまいの議論…11 10.1. サーバのコントロール接続の視点…11 10.2. サーバのデータ接続の視点…12 10.3. クライアントのコントロール接続の視点…14 10.4. クライアントのデータ接続の視点…15 11. だれが何を交渉するか、そして、どこ、およびどのように…15 11.1. 私たちはいったい保護しますか? ....................................15 11.2. 私たちはControl接続のときにどんなレベルの保護を使用しますか? ..............................................15 11.3. 私たちは一般に、データ接続を保護しますか? ...............16 11.4. 保護が特定のデータ転送に必要ですか? ...16 11.5. 保護のレベルが何であるかということであることが特定のデータに必要です…16 12. タイミングダイヤグラム…16 12.1. 保護されたセッションを確立します…17 12.2. パスワード要求なしで保護されたセッションを確立します…18 12.3. CCCと共にProtected Sessionを設立して、次に、Clearingを設立します…19 12.4. 保護のない標準のデータ転送…20 12.5. 保護のないファイアウォールに優しいデータ転送…20 12.6. 保護がある標準のデータ転送…21 12.7. 保護があるファイアウォールに優しいデータ転送…21 13. たづなコマンドの議論…22 14. スタットとABORの議論は命令します…22 15. セキュリティ問題…23 15.1. 認証トークンの検証…23 15.1.1. サーバ証明書…23 15.1.2. クライアント証明書…23 15.2. FTPセキュリティが問題[RFC-2577]であると扱います…24 15.2.1. バウンス攻撃…24 15.2.2. アクセスを制限します…24 15.2.3. パスワードを保護します…24 15.2.4. プライバシー…24 15.2.5. ユーザ名を保護します…24
Ford-Hutchinson Standards Track [Page 2] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[2ページ]RFC4217
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
15.2.6. 横取りを移植してください…25 15.2.7. ソフトウェアベースの警備上の問題…25 15.3. CCCの問題は命令します…25 16. IANA問題…25 17. 他のパラメタ…25 18. スケーラビリティと限界…26 19. 適用性…26 20. 承認…26 21. 参照…26 21.1. 標準の参照…26 21.2. 有益な参照…27
1. Introduction
1. 序論
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]
RFC959[RFC-959]
The description of the Internet File Transfer Protocol.
インターネットFile Transferプロトコルの記述。
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).
Transport Layer Securityプロトコル(Netscapeセキュリティソケットレイヤー(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].
このドキュメントがRFC2817[RFC-2817]のRFC3207[RFC-3207]とHTTPでFTPのサポートをSMTPに提供されたそれへの同様の方法で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はファイル転送を保証するための唯一のメカニズムではありませんが、以下の上向きの属性のいくつかを提供します:
Ford-Hutchinson Standards Track [Page 3] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[3ページ]RFC4217
- 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のアイデンティティを使用するのは可能です。
- 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のために既に適所にある認証機構がある共存とinteroperationは議定書を作ります。 これで、ウェブブラウザは、安全なウェブ閲覧を許容するためにセットアップされたのと同じインフラストラクチャを使用することで安全なファイル転送を取り入れることができます。
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社のSSLプロトコルの開発です、そして、FTPプロトコルがSSLかTLSのどちらかと共に使用されるのを許容するのにこのドキュメントは使用できます。 使用される実際のプロトコルは保護されたセッションの交渉でTLS/SSL層によって決められるでしょう。 このドキュメントはTLSプロトコルを示すだけでしょう。 しかしながら、それらがそのように構成されるならClientとServerが実際に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が柔軟性とinteroperationの両方を提供している間にしっかりと作動できる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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」 「5月」で「任意」は「推薦され」て、現れる中[RFC-2119]で説明されるように本書では解釈しないべきであることですか?
Ford-Hutchinson Standards Track [Page 4] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[4ページ]RFC4217
2. Audience
2. 聴衆
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]で議論したセキュリティ含意を百も承知しているべきです。]はこのプロトコルの実装を選んで、それらの必要なセキュリティを提供するためにそれを構成するとき、考えられる必要があります。
3. Overview
3. 概要
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セッションは正常な制御ポートの上で確立されます。 クライアントは、PBSZとPROTコマンドの使用でAUTHコマンドでTLSを要求して、次に、それが、データが接続であると機密保護したがっているかどうか決めます。 コントロール接続に平文(例えば、一度、認証フェーズは完成する)に先祖帰りをして戻らせるというクライアント願望、次に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.
このプロトコル拡大の実装はそれぞれとあらゆるセッションとデータ転送が確実に安全になるようにしません、とそれはクライアント、そして/または、サーバがその与えられたセッションかデータ転送のために許容できるか必要なレベルのセキュリティを交渉できるツールを単に、前提とします。 しかしながら、不安定なファッションで作動するのを拒否できるサーバ実装を持っているのは可能です。
4. Session Negotiation on the Control Port
4. 制御ポートのセッション交渉
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交渉が行われるのを許容するかもしれません。
4.1. Client Wants a Secured Session
4.1. クライアントは機密保護しているセッションが欲しいです。
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').
クライアントが願うなら、安全なaセッション、その時に試みるために、[RFC-2228]に従って、SHOULDはパラメタが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拒絶を受けるクライアントは、セッションが保護がない状態で続くのを選ぶかもしれません。
Ford-Hutchinson Standards Track [Page 5] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[5ページ]RFC4217
4.2. Server Wants a Secured Session
4.2. サーバは機密保護しているセッションを必要とします。
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プロトコルは、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.
しかし、AUTHコマンド、包含の後に転送パラメタをリセットしてください、(制限されない、)、: ユーザのアイデンティティ、デフォルトデータポート、TYPE、STRU、MODE、および現在の働くディレクトリ。
5. Clearing the Control Port
5. 制御ポートをきれいにします。
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.
通常、TLSプロトコルの中にAUTH、USER、PASS、PBSZ、およびPROTコマンドを保護するでしょう、そして、次に、平文ソケット状態に戻るためにCCCコマンドを発行するでしょう。 これには、重要なSecurity Issues(Security Considerations部で議論する)がありますが、このドキュメントはコマンドがどう使用されるべきであるかを説明します、問題を考えた後にクライアントとサーバがまだそれを使用していたいと思うなら。
Ford-Hutchinson Standards Track [Page 6] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[6ページ]RFC4217
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設定にすべての順次データ転送を保護しなければなりません。
6. Response to the FEAT Command
6. 功績命令への応答
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がコマンドであるとサポートするなら、回答におけるサポートしているAUTH、PBSZ、およびPROTコマンドの広告を出さなければなりません、[RFC-2389]のセクション3.2で説明されるように。 さらに、AUTHコマンドには、可能なパラメタの1つとして'TLS'をAUTHに特定する回答があるべきです。 別々に'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>S>AUTH TLS S>であるとサポートされた211拡大PBSZ S>PROT S>211END
Ford-Hutchinson Standards Track [Page 7] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[7ページ]RFC4217
7. Data Connection Behaviour
7. データ接続のふるまい
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.)
3つの方法の1つでFTPモデルのData Connectionを使用できます。 (以下に注意してください。 これらの記述は必ず正確な年代順に置かれるというわけではありませんが、必要であるステップについて説明してください。 後で明確化に関してダイヤグラムを見てください。)
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.
- クライアントはポートを入手します。 ポートナンバーをサーバに送ります。 サーバはクライアントに接します。 クライアント問題aは、コントロール接続のときに要求をサーバに送るか、または受け取ります、そして、データ転送はデータ接続を扱い始めます。
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.
- クライアントは、サーバが開港するよう要求します。 サーバは、クライアントにポートを入手して、アドレスとポートナンバーを返します。 クライアントはこのポートにサーバに接続します。 クライアント問題aは、コントロール接続に関する要求を送るか、または受け取ります、そして、データ転送はデータ接続を扱い始めます。
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.に接続するServerはサーバAへの要求とサーバBへの補数を送るか、または受け取ります、そして、データ転送は始まります。 このモデルでは、サーバAは、プロキシかPASVホストであり、サーバBへのData Connectionのためのクライアントです。
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].
を通してすなわち、どの側がaとの接続を開始するかが() 呼び出しに接するか、またはどれに面があるかが接続に反応するのが重要でない、() 呼び出しを受け入れてください。 いつも[RFC-959]で定義されるFTPクライアントは[RFC-2246]で定義されるようにTLSクライアントです。
Ford-Hutchinson Standards Track [Page 8] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[8ページ]RFC4217
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もTLSクライアントでないので、あります、FTPサーバがFirewall好意的なFTP[RFC-1579]のためのTLSサーバとして機能しなければならないという事実を考えて。 したがって、これは明らかにセキュリティ拡大ドキュメント[RFC-2228]に本書では除かれます。
8. Mechanisms for the AUTH Command
8. AUTHコマンドのためのメカニズム
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を交渉できます。 また、データ・チャンネルを保護するのに、PBSZコマンドを使用しなければなりません、続いて、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コマンドを発行するクライアントによって変更されるかもしれません。 このデータ・チャンネル保護交渉は任意な点でセッション(PORTかPASVコマンドの後まっすぐなさえ)にそのままで同じくらいしばしば必要な状態で起こることができます。
See also Section 16, "IANA Considerations".
セクション16も、「IANA問題」を見てください。
9. Data Connection Security
9. データ接続セキュリティ
The Data Connection security level is determined by the PROT command.
Data Connectionセキュリティー・レベルは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コマンドを発行するか、またはセッション(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]に沿って、不安定なControl接続とのData接続を保証するための施設が全くありません。 明確に、PBSZコマンドでPROTコマンドに先行しなければなりません、そして、うまくいっているセキュリティデータ交換(この場合、TLS交渉)でPBSZコマンドに先行しなければなりません。
Ford-Hutchinson Standards Track [Page 9] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[9ページ]RFC4217
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'--クリアしてください--、どちらもIntegrityかPrivacy
'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、(超過、)、秘密の、または、Safe/個人的な区別、兵士(TLSを使用する)、およびClear(TLSを使用しない)だけが使用されています。
For TLS, the data connection can have one of two security levels.
TLSに関しては、データ接続は2つのセキュリティー・レベルの1つを持つことができます。
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交渉は接続の上に送られるどんなデータの前にもデータ接続のときにClientとServerの満足に行われなければなりません。 ClientとServerのTLS層は使用される正確なTLS Cipher Suites(そして、その結果、接続の最後のセキュリティ)を交渉するのに原因となるようになるでしょう。
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-TLSに関しては、これは必要ではありません。(TLSはストリーミングの保護メカニズムとしてFTPアプリケーションに見えます)。 したがって、PBSZコマンドには、まだ発行しなければなりませんが、バッファリングでないのが行われることであって、データ接続がカプセル化されるべきでないのを示す'0'のパラメタがなければなりません。
Note that PBSZ 0 is not in the grammar of [RFC-2228], section 8.1,
where it is stated:
PBSZ0が[RFC-2228]の文法、それが述べられているセクション8.1にないことに注意してください:
Ford-Hutchinson Standards Track [Page 10] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[10ページ]RFC4217
PBSZ <sp> <decimal-integer> <CRLF> <decimal-integer> ::= any
decimal integer from 1 to (2^32)-1
10進整数のPBSZの<CRLF><10進整数の<sp><>>:、:= どんな10進整数1〜(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]によって示されるようにこれはふるまいです)。
10. A Discussion of Negotiation Behaviour
10. 交渉のふるまいの議論
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]が、セキュリティ品質がダイナミックに交渉されて、可能にされて、無効にされるのを許容するように、これは実装をかなり複雑に見せることができます。 しかしながら、どんな与えられたインスタンスでも、ふるまいはかなり正直であるべきです。 サーバがサーバー・ホストの方針を実施するだろうか、またはそれはクライアントによって要求されたセキュリティ能力を提供するでしょう。 クライアントは、サーバの方針に従うか、またはユーザが望んでいる能力を提供するのに尽力するでしょう。
10.1. The Server's View of the Control Connection
10.1. サーバのコントロール接続の視点
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/匿名の)のために不安定なUSERコマンドを否定してください。
- Deny secure USER commands for certain users (e.g.,
ftp/anonymous).
- 確信しているユーザのために安全なUSERコマンドを否定してください、(例えば、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).
- 使用できた(恐らくhost/domain/…基礎あたりのaに関して)CipherSuitesを定義してください。
- Allow TLS authentication as a substitute for local
authentication.
- 地方の認証の代用品としてTLSに認証を許してください。
Ford-Hutchinson Standards Track [Page 11] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[11ページ]RFC4217
- 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.
この場合、コントロール接続が保護のないモードでまだそうあるべきです、そして、サーバSHOULDはセッションを終わらせるために保護のない'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交渉、サーバだけがセッションパラメタが許容できないと決めます(例えば、クライアント証明書のDistinguished Nameがサーバを使用することが許可されていません)。
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.
この場合、コントロール接続が未知の状態にあります、そして、サーバSHOULDは単にコントロール接続を下げます。
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.
サーバコードは必要な政策を実施して、クライアントが方針に反対しているそれらのコマンドを修理するのを拒否することによって選ばれたセキュリティを回避するのが防がれるのを確実にするのに原因となるようになるでしょう。
10.2. The Server's View of the Data Connection
10.2. サーバのデータ接続の視点
The server can take one of four basic views of the data connection.
サーバはデータ接続の4つの基本的な眺めの1つを取ることができます。
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つのものの1つを決めてください。
Ford-Hutchinson Standards Track [Page 12] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[12ページ]RFC4217
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.
サーバSHOULDはデータ転送(そして、PORTかいずれのPASVでも、そうしない)に着手する実際のコマンドのデータ保護レベル(上のオプション3と4のための)の状態をチェックするだけです。 [RFC-959]で定義された以下のコマンドは、データ接続が開かれることを引き起こして、その結果、どんな1xxメッセージの前にも不正確なPROT設定のため拒絶されるかもしれません。
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交渉が失敗するか、または容認できなかったのを示します)。 (注意: これは、アプリケーションが交渉、およびレビューのためのTLS層へのCipherSuitesの標準のリストに適用性のためにどの場合にも交渉されたものを通過できることを意味します)。
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部は、コントロール接続を認証するために使用されるもの(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認証がサーバー・ホストにおけるユーザではなく、サーバー・ホスト自身の認証になることに注意されるべきです。
Ford-Hutchinson Standards Track [Page 13] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[13ページ]RFC4217
10.3. The Client's View of the Control Connection
10.3. クライアントのコントロール接続の視点
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を使用しそうでしょう。 これを考慮してください、クライアントSHOULD。適切な時期でセッションを機密保護することを管理して、ユーザ/サーバ方針が、セッションの間、セキュリティがちょうどいつ交渉されるかを決めるのをまだ許容しているほどフレキシブルであってください。
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コマンドのタイミングを許容するほどコード化されてください。クライアントSHOULD、サーバがこれらのコマンドの前に、あるコマンドを拒否するのは、かなり妥当です。 同様に、SITEか引用されたコマンドが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.
例えば、クライアントSHOULD NOTは、セッションにおける最初のコマンドとして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交渉はクライアントのために満足に終了しないかもしれません、その場合、それはこれらの州の1つにあるでしょう:
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交渉、クライアントだけがセッションパラメタが許容できないと決めます(例えば、証明書のDistinguished Nameは予想された実際のサーバではありません)。
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コマンドを発行するべきです。
Ford-Hutchinson Standards Track [Page 14] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[14ページ]RFC4217
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.
この場合、コントロール接続が未知の状態にあります、そして、クライアントは単にコントロール接続を下げるべきです。
10.4. The Client's View of the Data Connection
10.4. クライアントのデータ接続の視点
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.
クライアントにはそういうものの'方針'が通常なくて、それらは、代わりに、彼らの動作を定義するためにユーザに頼って、ある程度サーバ方針に反応しています。 したがって、クライアントはユーザがダイナミックにデータ接続の保護レベルを切り換えることができるコマンドを必要とするでしょう。 しかしながら、最初に(そして、自動的に、失敗するなら、兵士に切り替わる)Clear接続のときにすべてのLISTと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認証がクライアントホストではなく、クライアントホスト自身におけるユーザの認証であるべきであることに注意されるべきです。
11. Who Negotiates What, Where, and How
11. だれが何を交渉するか、そして、どこ、およびどのように
11.1. Do we protect at all?
11.1. 私たちはいったい保護しますか?
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を必要とするなら、それは、首尾よく保護されたセッションを得るまであるコマンドを受け入れるのを拒否します。
11.2. What level of protection do we use on the Control connection?
11.2. 私たちはControl接続のときにどんなレベルの保護を使用しますか?
Decided entirely by the TLS CipherSuite negotiation.
完全にTLS CipherSuite交渉で、決められます。
Ford-Hutchinson Standards Track [Page 15] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[15ページ]RFC4217
11.3. Do we protect data connections in general?
11.3. 私たちは一般に、データ接続を保護しますか?
Client issues PROT command, server accepts or rejects.
クライアントはPROTコマンド、サーバを支給します。受け入れるか、または拒絶します。
11.4. Is protection required for a particular data transfer?
11.4. 保護が特定のデータ転送に必要ですか?
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 CipherSuitesを定義して、発見するために座るTLS層と対話できるのが、望ましいのがわかることができます。
12. Timing Diagrams
12. タイムチャート
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]でコマンドと応答のタイミングに関してよく説明されないので、これは既存の広範囲のクライアントとサーバ実装の経験的観察に一部基づいています。
Ford-Hutchinson Standards Track [Page 16] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[16ページ]RFC4217
12.1. Establishing a Protected Session
12.1. 保護されたセッションを確立します。
Client Server
control data data control
====================================================================
クライアントServer制御データデータコントロール====================================================================
socket()
bind()
socket()
connect() ----------------------------------------------> accept()
<---------------------------------------------- 220
AUTH TLS ---------------------------------------------->
<---------------------------------------------- 234
TLSneg() <----------------------------------------------> TLSneg()
PBSZ 0 ---------------------------------------------->
<---------------------------------------------- 200
PROT P ---------------------------------------------->
<---------------------------------------------- 200
USER fred ---------------------------------------------->
<---------------------------------------------- 331
PASS pass ---------------------------------------------->
<---------------------------------------------- 230
ソケット()ひもの()ソケット()は()を接続します。---------------------------------------------->は() <を受け入れます。---------------------------------------------- 220AUTH TLS----------------------------------------------><。---------------------------------------------- 234 TLSneg()<。---------------------------------------------->TLSneg() PBSZ0----------------------------------------------><。---------------------------------------------- 200 PROT P----------------------------------------------><。---------------------------------------------- 200 USER fred----------------------------------------------><。---------------------------------------------- 331PASSが通ります。----------------------------------------------><。---------------------------------------------- 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: PASSコマンドは全く必要でないかもしれません(USERパラメタとアイデンティティが提示したどれかクライアントが十分な認証を提供するなら)。 サーバは、'331'の代わりにUSERコマンドに'232'回答を発行することによって、これを示すでしょう(以下を見てください)。(コマンドはクライアントからPASSを要求します)。
Note 3: The AUTH command might not be the first command after the receipt of the 220 welcome message.
注意3: AUTHコマンドは220歓迎メッセージの領収書の後の最初のコマンドでないかもしれません。
Ford-Hutchinson Standards Track [Page 17] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[17ページ]RFC4217
12.2. Establishing a Protected Session Without a Password Request
(The TLS Authentication is Sufficient)
12.2. パスワード要求なしで保護されたセッションを確立します。(TLS AuthenticationはSufficientです)
Client Server
control data data control
====================================================================
クライアントServer制御データデータコントロール====================================================================
socket()
bind()
socket()
connect() ----------------------------------------------> accept()
<---------------------------------------------- 220
AUTH TLS ---------------------------------------------->
<---------------------------------------------- 234
TLSneg() <----------------------------------------------> TLSneg()
PBSZ 0 ---------------------------------------------->
<---------------------------------------------- 200
PROT P ---------------------------------------------->
<---------------------------------------------- 200
USER fred ---------------------------------------------->
<---------------------------------------------- 232
ソケット()ひもの()ソケット()は()を接続します。---------------------------------------------->は() <を受け入れます。---------------------------------------------- 220AUTH TLS----------------------------------------------><。---------------------------------------------- 234 TLSneg()<。---------------------------------------------->TLSneg() PBSZ0----------------------------------------------><。---------------------------------------------- 200 PROT P----------------------------------------------><。---------------------------------------------- 200 USER fred----------------------------------------------><。---------------------------------------------- 232
Ford-Hutchinson Standards Track [Page 18] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[18ページ]RFC4217
12.3. Establishing a Protected Session and then Clearing with the CCC
Command
12.3. CCC Commandと共にProtected Sessionを設立して、次に、Clearingを設立します。
Client Server
control data data control
====================================================================
クライアントServer制御データデータコントロール====================================================================
socket()
bind()
socket()
connect() ----------------------------------------------> accept()
<---------------------------------------------- 220
AUTH TLS ---------------------------------------------->
<---------------------------------------------- 234
TLSneg() <----------------------------------------------> TLSneg()
PBSZ 0 ---------------------------------------------->
<---------------------------------------------- 200
PROT P ---------------------------------------------->
<---------------------------------------------- 200
USER fred ---------------------------------------------->
<---------------------------------------------- 232
CCC ---------------------------------------------->
<---------------------------------------------- 200
TLSshutdown() <-------------------------------------> TLSshutdown()
ソケット()ひもの()ソケット()は()を接続します。---------------------------------------------->は() <を受け入れます。---------------------------------------------- 220AUTH TLS----------------------------------------------><。---------------------------------------------- 234 TLSneg()<。---------------------------------------------->TLSneg() PBSZ0----------------------------------------------><。---------------------------------------------- 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.
以下に注意してください。 これは、重大な安全保障問題(Security Considerations部を見る)を持っていますが、ファイアウォール/NATシナリオで役に立つかもしれません。
Ford-Hutchinson Standards Track [Page 19] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[19ページ]RFC4217
12.4. A Standard Data Transfer Without Protection
12.4. 保護のない標準のデータ転送
Client Server
control data data control
====================================================================
クライアントServer制御データデータコントロール====================================================================
socket()
bind()
PORT w,x,y,z,a,b ----------------------------------------->
<----------------------------------------------------- 200
STOR file ------------------------------------------------>
socket()
bind()
<----------------------------------------------------- 150
accept() <----------- connect()
write() -----------> read()
close() -----------> close()
<----------------------------------------------------- 226
ソケット()ひも()PORT w、x、y、z、a、b-----------------------------------------><。----------------------------------------------------- 200 STORはファイルします。------------------------------------------------>ソケット()ひも()<。----------------------------------------------------- 150は() <を受け入れます。----------- 接続、() ()を書いてください。-----------() 閉鎖()が読まれた>。----------->閉鎖()<。----------------------------------------------------- 226
12.5. A Firewall-Friendly Data Transfer Without Protection
12.5. 保護のないファイアウォールに優しいデータ転送
Client Server
control data data control
====================================================================
クライアントServer制御データデータコントロール====================================================================
PASV -------------------------------------------------------->
socket()
bind()
<------------------------------------------ 227 (w,x,y,z,a,b)
socket()
STOR file --------------------------------------------------->
connect() ----------> accept()
<-------------------------------------------------------- 150
write() ----------> read()
close() ----------> close()
<-------------------------------------------------------- 226
PASV-------------------------------------------------------->ソケット()ひも()<。------------------------------------------ 227(w、x、y、z、a、b)ソケット()STORファイル--------------------------------------------------->は()を接続します。---------->は() <を受け入れます。-------------------------------------------------------- 150は()を書きます。----------() 閉鎖()が読まれた>。---------->閉鎖()<。-------------------------------------------------------- 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.
以下に注意してください。 /が受け入れる()を接続してください。Implementersが意識しているべきである、それ、()機能は回答の領収書の前でSTORコマンドから実行されます。 /が接続する()を受け入れてください。そして、これが対照をなす、状況、aである、非、-ファイアウォール好意的なPORTがSTORの前で使用される、()は回答の後にSTORが取扱われた前述から実行されます。
Ford-Hutchinson Standards Track [Page 20] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[20ページ]RFC4217
12.6. A Standard Data Transfer with Protection
12.6. 保護がある標準のデータ転送
Client Server
control data data control
====================================================================
クライアントServer制御データデータコントロール====================================================================
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
ソケット()ひも()PORT w、x、y、z、a、b--------------------------------------------><。-------------------------------------------------------- 200 STORはファイルします。--------------------------------------------------->ソケット()ひも()<。-------------------------------------------------------- 150は() <を受け入れます。---------- () TLSneg()<を接続してください。---------->TLSneg() TLSwrite()---------->TLSread() TLSshutdown()------->TLSshutdown()は()を閉じます。---------->閉鎖()<。-------------------------------------------------------- 226
12.7. A Firewall-Friendly Data Transfer with Protection
12.7. 保護があるファイアウォールに優しいデータ転送
Client Server
control data data control
====================================================================
クライアントServer制御データデータコントロール====================================================================
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
PASV-------------------------------------------------------->ソケット()ひも()<。------------------------------------------ 227(w、x、y、z、a、b)ソケット()STORファイル--------------------------------------------------->は()を接続します。---------->は() <を受け入れます。-------------------------------------------------------- 150 TLSneg()<。--------->TLSneg() TLSwrite()--------->TLSread() TLSshutdown()------->TLSshutdown()は()を閉じます。--------->閉鎖()<。-------------------------------------------------------- 226
Ford-Hutchinson Standards Track [Page 21] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[21ページ]RFC4217
13. Discussion of the REIN Command
13. たづなコマンドの議論
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(たづな)
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.
このコマンドは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.
TLSセッションをクリアするのにREINコマンドを使用しているなら、クリアされるセッションの前に保護されたセッションのときにREINコマンドに関する回答を送らなければなりません。
14. Discussion of the STAT and ABOR Commands
14. スタットとABORコマンドの議論
The ABOR and STAT commands and the use of TCP Urgent Pointers
ABOR、STATコマンド、およびTCP Urgent Pointersの使用
[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 Urgent指針の使用について説明します。 FTPは2つのコマンドについて前書きするのにUrgentデータに関連してTelnet Interrupt ProcessとDataマークコマンドを使用します: ABOR(Transferを中止する)と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実装では、UrgentとしてマークされたTCPパケットの領収書はSIGURG割り込みハンドラの実行をもたらすでしょう、したがって、Urgent Pointerが使用されました。 割り込みハンドラへのこの信用が選んだ()を実装しなかったか、または複数のスレッドをサポートしなかったシステムの上で必要でした。 TLSはUrgentデータの概念をサポートしません。
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におけるセキュリティメソッドとして実装されるとき、サーバSHOULD NOTは、データ転送の間、制御チャンネルに入力を処理するためにSIGURGの使用に依存します。 クライアントはTLSセッションの向こう側にTelnetコマンドを含むすべてのデータを送らなければなりません。
Ford-Hutchinson Standards Track [Page 22] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[22ページ]RFC4217
15. Security Considerations
15. セキュリティ問題
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]ドキュメントの中に含まれていて、ここで繰り返されません。
15.1. Verification of Authentication Tokens
15.1. 認証トークンの検証
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]を見てください)、同様の、そして、メカニズム特有の問題は、作られている必要があるでしょう。
15.1.1. Server Certificates
15.1.1. サーバ証明書
- 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.
- Data接続のサーバ証明に使用される証明書が対応するControl接続に使用されるそれと同じ証明書であることが強く推薦されます。 異なった証明書が使用されていることであるなら、クライアントがデータとコントロール接続サーバのアイデンティティにクロスチェックするのに使用できるある他のメカニズムがあるはずです。
- 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.
- Server Certificatesが使用されていないと、セキュリティ利益の多くがわからないでしょう。 中の男性に対する保護がほとんどなくて、Exampleのために、匿名のディフィー-ヘルマン環境には、サーバアイデンティティ認証が全くない、-、-中央は攻撃されます。
15.1.2. Client Certificates
15.1.2. クライアント証明書
- 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.
- しかしながら、Data接続のクライアント認証に使用される証明書が対応するControl接続に使用されるそれと同じ証明書であることが強く推薦されます。 異なった証明書が使用されていることであるなら、サーバがデータとコントロール接続クライアントのアイデンティティにクロスチェックするのに使用できるある他のメカニズムがあるはずです。
Ford-Hutchinson Standards Track [Page 23] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[23ページ]RFC4217
- 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.
- Client Certificatesが使用されていないと、セキュリティ利益の多くがわからないでしょう。 Exampleに関しては、悪意があるクライアントがデータ接続をハイジャックするのは、まだ可能でしょう。
15.2. Addressing FTP Security Considerations [RFC-2577]
15.2. FTPセキュリティが問題であると扱います。[RFC-2577]
15.2.1. Bounce Attack
15.2.1. バウンス攻撃
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サーバへのアクセスをより得そうにはありません。(パスワード推測、ネットワークのたどること。)
15.2.2. Restricting Access
15.2.2. アクセスを制限します。
This document presents a strong mechanism for solving the issue raised in this section.
このドキュメントは、このセクションで提起された問題を解決するために強いメカニズムを提示します。
15.2.3. Protecting Passwords
15.2.3. パスワードを保護します。
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がコントロールセッションを保護するのに使用されるとき、これが問題でないことを確実にします。
15.2.4. Privacy
15.2.4. プライバシー
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] おそらく)
15.2.5. Protecting Usernames
15.2.5. ユーザ名を保護します。
This is not an issue when TLS is used as the primary authentication mechanism.
TLSがプライマリ認証機構として使用されるとき、これは問題ではありません。
Ford-Hutchinson Standards Track [Page 24] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[24ページ]RFC4217
15.2.6. Port Stealing
15.2.6. ポート横取り
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.
この仕様はこのセクションのサービス妨害原理のために少ししかしないでしょう。 しかしながら、データ接続の強い認証は、権限のない接続がファイルを取るか、または提出するのを防ぐでしょう。 もちろん、唯一のこれは強いクライアント認証が使用されているそうです。 クライアント証明書が使用されていないなら、それでも、凶暴なクライアントで横取りするポートは問題です。 強い認証が全く使用中でないなら(例えば、匿名のディフィー・ヘルマン)、ポート横取りの問題は残るでしょう。
15.2.7. Software-Based Security Problems
15.2.7. ソフトウェアベースの警備上の問題
Nothing in this specification will affect the discussion in this section.
この仕様による何もこのセクションで議論に影響しないでしょう。
15.3. Issues with the CCC Command
15.3. CCCコマンドの問題
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]の「明確な指揮系統(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 USER/PASS)を通り抜けていないセッションのときにCCCコマンドを処理するのを拒否したがっているかもしれません。 これによって、匿名のクライアントは、サーバにリソースをタイアップするよう繰り返してCCCによって続かれたAUTH TLSに要求できません。
16. IANA Considerations
16. IANA問題
{FTP-PORT} - The port assigned to the FTP control connection is 21.
FTP-PORT--FTPコントロール接続に割り当てられたポートは21です。
17. Other Parameters
17. 他のパラメタ
{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--そのTLSを示すAUTHコマンドのためのパラメタが必要です。 このドキュメントによると、TLSプロトコルを要求するために、クライアントは'TLS'を使用しなければなりません。
To maintain backward compatibility with older versions of this
document, the server SHOULD accept 'TLS-C' as a synonym for 'TLS'.
このドキュメントの旧式のバージョンとの後方の互換性を維持するために、サーバSHOULDは'TLS'のための同義語として'TLS-C'を認めます。
Note: [RFC-2228] states that these parameters are case-
insensitive.
以下に注意してください。 [RFC-2228]は、これらのパラメタがケース神経が鈍いと述べます。
Ford-Hutchinson Standards Track [Page 25] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[25ページ]RFC4217
18. Scalability and Limits
18. スケーラビリティと限界
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交渉を持つのを拒否する能力に関するもの以外の問題が全くありません。
19. Applicability
19. 適用性
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クライアントかサーバがそのようなセキュリティを必要とするのは(何かが秘密性のない認証機能のようにそうするかもしれませんが)、ありそうもないです。
20. Acknowledgements
20. 承認
o Netscape Communications Corporation for the original SSL protocol.
o オリジナルのSSLプロトコルのためのネットスケープ社。
o Eric Young for the SSLeay libraries.
o SSLeayライブラリへのエリック・ヤング。
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 ABORとSTAT議論のためのジェフ・アルトマン。
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 助けを持っている様々な人々は延長された草稿ステージ、すなわち、マーチンCarpenter、エリック・マレー、ティム・ハドソン、およびボルカー・ウィーガント中にこのドキュメントを書きます。
21. References
21. 参照
21.1. Normative References
21.1. 引用規格
[RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD
9, RFC 959, October 1985.
[RFC-959] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC-2228] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
2228, October 1997.
[RFC-2228] ホロビッツとM.とS.ラント、「FTPセキュリティ拡大」、RFC2228、1997年10月。
Ford-Hutchinson Standards Track [Page 26] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[26ページ]RFC4217
[RFC-2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC-2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[RFC-2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for
the File Transfer Protocol", RFC 2389, August 1998.
[RFC-2389] ヘスマンとP.とR.Elz、「File Transferプロトコルのための特徴交渉メカニズム」、RFC2389、1998年8月。
21.2. Informative References
21.2. 有益な参照
[RFC-1579] Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February
1994.
[RFC-1579] Bellovin、S.、「ファイアウォールに優しいFTP」、RFC1579、1994年2月。
[RFC-2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC-2222] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[RFC-2577] Allman, M. and S. Ostermann, "FTP Security
Considerations", RFC 2577, May 1999.
[RFC-2577] オールマン、M.、およびS.オステルマン(「FTPセキュリティ問題」、RFC2577)は1999がそうするかもしれません。
[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)へのケルベロス暗号スイートの追加」、RFC2712、1999年10月。
[RFC-2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
「HTTP/1.1インチ、RFC2817、2000年5月中にTLSにアップグレードする」[RFC-2817]Khare、R.、およびS.ローレンス。
[RFC-2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC-2818]レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。
[RFC-3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[RFC-3207]ホフマン、P.、「トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子」、RFC3207、2002年2月。
Ford-Hutchinson Standards Track [Page 27] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[27ページ]RFC4217
Contributors
貢献者
Tim Hudson RSA Data Security Australia Pty Ltd
ティム・ハドソンRSA Data Securityオーストラリア管理会社
Phone: +61 7 3227 4444 EMail: tjh@rsasecurity.com.au
以下に電話をしてください。 +61 7 3227 4444はメールされます: tjh@rsasecurity.com.au
Volker Wiegand SuSE Linux
ボルカーウィーガントSuSE Linux
EMail: wiegand@suse.de
メール: wiegand@suse.de
Martin Carpenter Verisign Ltd
マーチン大工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イギリスのLtd私書箱31バーミンガム道路ウォリックイギリス
Phone: +44 1926 462005 EMail: rfc4217@ford-hutchinson.com
以下に電話をしてください。 +44 1926 462005はメールされます: rfc4217@ford-hutchinson.com
Ford-Hutchinson Standards Track [Page 28] RFC 4217 Securing FTP with TLS October 2005
2005年10月にTLSと共にFTPを保証するフォード-ハッチンソン標準化過程[28ページ]RFC4217
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Ford-Hutchinson Standards Track [Page 29]
フォード-ハッチンソン標準化過程[29ページ]
一覧
スポンサーリンク
