RFC2228 日本語訳
2228 FTP Security Extensions. M. Horowitz, S. Lunt. October 1997. (Format: TXT=58733 bytes) (Updates RFC0959) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Horowitz
Request for Comments: 2228 Cygnus Solutions
Updates: 959 S. Lunt
Category: Standards Track Bellcore
October 1997
コメントを求めるワーキンググループM.ホロビッツ要求をネットワークでつないでください: 2228の白鳥座ソリューションアップデート: 959秒間ラントCategory: 標準化過程Bellcore1997年10月
FTP Security Extensions
FTPセキュリティ拡大
Status of this Memo
この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 (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 All rights reserved。
Abstract
要約
This document defines extensions to the FTP specification STD 9, RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985). These extensions provide strong authentication, integrity, and confidentiality on both the control and data channels with the introduction of new optional commands, replies, and file transfer encodings.
このドキュメントはSTD9、RFC959、「ファイル転送プロトコル(FTP)」(1985年10月)というFTP仕様と拡大を定義します。 これらの拡大はコントロールとデータ・チャンネルの両方で新しい任意のコマンド、回答、およびファイル転送encodingsの導入に強い認証、保全、および秘密性を提供します。
The following new optional commands are introduced in this specification:
以下の新しい任意のコマンドはこの仕様で紹介されます:
AUTH (Authentication/Security Mechanism),
ADAT (Authentication/Security Data),
PROT (Data Channel Protection Level),
PBSZ (Protection Buffer Size),
CCC (Clear Command Channel),
MIC (Integrity Protected Command),
CONF (Confidentiality Protected Command), and
ENC (Privacy Protected Command).
AUTH(認証/セキュリティー対策)、ADAT(認証/セキュリティー・データ)、PROT(データ・チャンネル保護レベル)、PBSZ(保護バッファサイズ)、CCC(明確な指揮系統)、MIC(保全はコマンドを保護した)、CONF(秘密性はコマンドを保護した)、およびENC(プライバシーはコマンドを保護しました)。
A new class of reply types (6yz) is also introduced for protected replies.
また、保護された回答のために、新しいクラスの回答タイプ(6yz)を導入します。
None of the above commands are required to be implemented, but interdependencies exist. These dependencies are documented with the commands.
上のコマンドのいずれも実装されるのに必要ではありませんが、相互依存性は存在しています。 これらの依存はコマンドで記録されます。
Note that this specification is compatible with STD 9, RFC 959.
RFC959、この仕様はSTD9と互換性があることに注意してください。
Horowitz & Lunt Standards Track [Page 1] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[1ページ]。
1. Introduction
1. 序論
The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959 and in place on the Internet uses usernames and passwords passed in cleartext to authenticate clients to servers (via the USER and PASS commands). Except for services such as "anonymous" FTP archives, this represents a security risk whereby passwords can be stolen through monitoring of local and wide-area networks. This either aids potential attackers through password exposure and/or limits accessibility of files by FTP servers who cannot or will not accept the inherent security risks.
現在インターネットでSTD9、RFC959と適所で定義されているFile Transferプロトコル(FTP)はサーバ(USERとPASSコマンドを通した)にクライアントを認証するためにcleartextで通過されたユーザ名とパスワードを使用します。 「匿名」のFTPアーカイブなどのサービスを除いて、これは地方のモニターでパスワードを盗むことができるセキュリティリスクと広域ネットワークを表します。 これは、パスワード暴露を通して潜在的攻撃者を支援する、そして/または、そうすることができないFTPサーバでファイルのアクセシビリティを制限するか、または固有のセキュリティ危険を受け入れないでしょう。
Aside from the problem of authenticating users in a secure manner, there is also the problem of authenticating servers, protecting sensitive data and/or verifying its integrity. An attacker may be able to access valuable or sensitive data merely by monitoring a network, or through active means may be able to delete or modify the data being transferred so as to corrupt its integrity. An active attacker may also initiate spurious file transfers to and from a site of the attacker's choice, and may invoke other commands on the server. FTP does not currently have any provision for the encryption or verification of the authenticity of commands, replies, or transferred data. Note that these security services have value even to anonymous file access.
また、安全な方法でユーザを認証するという問題は別として、サーバを認証するという問題があります、極秘データを保護する、そして/または、保全について確かめて。 攻撃者は、保全を崩壊させるように移されるデータを、単にネットワークをモニターすることによって貴重であるか機密のデータにアクセスできるか、削除するか、またはアクティブな手段で変更できるかもしれません。 活発な攻撃者は、また、場所と攻撃者の選択の場所から偽りのファイル転送を開始して、サーバに他のコマンドを呼び出すかもしれません。FTPには、現在、暗号化へのどんな支給かコマンド、回答、またはわたっているデータの信憑性の検証もありません。 これらのセキュリティー・サービスが匿名のファイルアクセスにさえ値を持っていることに注意してください。
Current practice for sending files securely is generally either:
一般に、しっかりとファイルを送るための現在の習慣はどちらかです:
1. via FTP of files pre-encrypted under keys which are manually
distributed,
1. キーの下であらかじめ暗号化されたファイルのFTPで、どれが手動で分配されるか。
2. via electronic mail containing an encoding of a file encrypted
under keys which are manually distributed,
2. 電子メール含有を通した手動で分配されるキーの下で暗号化されたファイルのコード化
3. via a PEM message, or
または3. PEMを通して、通信してください。
4. via the rcp command enhanced to use Kerberos.
4. rcpを通して、コマンドはケルベロスを使用に高めました。
None of these means could be considered even a de facto standard, and none are truly interactive. A need exists to securely transfer files using FTP in a secure manner which is supported within the FTP protocol in a consistent manner and which takes advantage of existing security infrastructure and technology. Extensions are necessary to the FTP specification if these security services are to be introduced into the protocol in an interoperable way.
デファクトスタンダードでさえあるとこれらの手段のどれかを考えることができませんでした、そして、本当に、なにも対話的ではありません。 必要性は、FTPプロトコルの中で一貫した方法でサポートされて、既存のセキュリティインフラストラクチャを利用する安全な方法と技術でFTPを使用することでしっかりとファイルを移すために存在しています。 拡大がこれらのセキュリティー・サービスが共同利用できる方法でプロトコルに導入することであるならFTP仕様に必要です。
Horowitz & Lunt Standards Track [Page 2] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[2ページ]。
Although the FTP control connection follows the Telnet protocol, and Telnet has defined an authentication and encryption option [TELNET- SEC], [RFC-1123] explicitly forbids the use of Telnet option negotiation over the control connection (other than Synch and IP).
FTPコントロール接続はTelnetプロトコルに従います、そして、Telnetは認証と暗号化オプション[TELNET SEC]を定義しましたが、[RFC-1123]は明らかにコントロール接続(SynchとIPを除いた)の上のTelnetオプション交渉の使用を禁じます。
Also, the Telnet authentication and encryption option does not provide for integrity protection only (without confidentiality), and does not address the protection of the data channel.
また、Telnet認証と暗号化オプションは、保全保護だけに備えないで、またデータ・チャンネルの保護を扱いません。
2. FTP Security Overview
2. FTPセキュリティ概要
At the highest level, the FTP security extensions seek to provide an abstract mechanism for authenticating and/or authorizing connections, and integrity and/or confidentiality protecting commands, replies, and data transfers.
上層部によって、FTPセキュリティ拡大はコマンド、回答、およびデータ転送を保護する接続と、保全、そして/または、秘密性に認証する、そして/または、権限を与えるのに抽象的なメカニズムを提供しようとします。
In the context of FTP security, authentication is the establishment of a client's identity and/or a server's identity in a secure way, usually using cryptographic techniques. The basic FTP protocol does not have a concept of authentication.
FTPセキュリティの文脈に、通常、暗号のテクニックを使用して、認証は安全な方法でクライアントのアイデンティティ、そして/または、サーバのアイデンティティの設立です。 基本的なFTPプロトコルには、認証の概念がありません。
Authorization is the process of validating a user for login. The basic authorization process involves the USER, PASS, and ACCT commands. With the FTP security extensions, authentication established using a security mechanism may also be used to make the authorization decision.
承認はログインのためにユーザを有効にするプロセスです。 基本認可プロセスはUSER、PASS、およびACCTコマンドにかかわります。 また、FTPセキュリティ拡大と共に、セキュリティー対策を使用することで確立された認証は、承認決定をするのに使用されるかもしれません。
Without the security extensions, authentication of the client, as this term is usually understood, never happens. FTP authorization is accomplished with a password, passed on the network in the clear as the argument to the PASS command. The possessor of this password is assumed to be authorized to transfer files as the user named in the USER command, but the identity of the client is never securely established.
セキュリティ拡大がなければ、今期が通常理解されているとき、クライアントの認証は決して起こりません。 ネットワークは、PASSコマンドへの議論としての明確でFTP承認がパスワードで達成されると伝えました。 USERコマンドで指定されたユーザとしてファイルを移すのがこのパスワードの所有者が認可されると思われますが、クライアントのアイデンティティはしっかりと決して確立されません。
An FTP security interaction begins with a client telling the server what security mechanism it wants to use with the AUTH command. The server will either accept this mechanism, reject this mechanism, or, in the case of a server which does not implement the security extensions, reject the command completely. The client may try multiple security mechanisms until it requests one which the server accepts. This allows a rudimentary form of negotiation to take place. (If more complex negotiation is desired, this may be implemented as a security mechanism.) The server's reply will indicate if the client must respond with additional data for the
クライアントが、それがAUTHコマンドと共にどんなセキュリティー対策を使用したがっているかをサーバに言っていて、FTPセキュリティ相互作用は始まります。 サーバは、このメカニズムを受け入れるか、このメカニズムを拒絶するか、またはセキュリティが拡大であると実装しないサーバの場合でコマンドを完全に拒絶するでしょう。 サーバが受け入れるものを要求するまで、クライアントは複数のセキュリティー対策を試すかもしれません。 これで、初歩的な形式の交渉は行われます。 (より複雑な交渉が望まれているなら、これはセキュリティー対策として実装されるかもしれません。) クライアントが追加データで応じなければならないかどうかを示すためにサーバの回答は望んでいます。
Horowitz & Lunt Standards Track [Page 3] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[3ページ]。
security mechanism to interpret. If none is needed, this will usually mean that the mechanism is one where the password (specified by the PASS command) is to be interpreted differently, such as with a token or one-time password system.
解釈するセキュリティー対策。 なにも必要でないなら、通常、これは、メカニズムが異なって解釈されるパスワード(PASSコマンドで、指定される)がことであるものであることを意味するでしょう、トークンやワンタイムパスワードシステムなどのように。
If the server requires additional security information, then the client and server will enter into a security data exchange. The client will send an ADAT command containing the first block of security data. The server's reply will indicate if the data exchange is complete, if there was an error, or if more data is needed. The server's reply can optionally contain security data for the client to interpret. If more data is needed, the client will send another ADAT command containing the next block of data, and await the server's reply. This exchange can continue as many times as necessary. Once this exchange completes, the client and server have established a security association. This security association may include authentication (client, server, or mutual) and keying information for integrity and/or confidentiality, depending on the mechanism in use.
サーバが追加担保情報を必要とすると、クライアントとサーバはセキュリティデータ交換に入るでしょう。 クライアントはセキュリティー・データの最初のブロックを含むADATコマンドを送るでしょう。 サーバの回答は、データ交換が完全であるかどうかを示すでしょう、誤りがあったか、または、より多くのデータが必要であるなら。 サーバの回答は任意にクライアントが解釈するセキュリティー・データを含むことができます。 より多くのデータが必要であるなら、クライアントは、データの次のブロックを含む別のADATコマンドを送って、サーバの回答をお待ちするでしょう。 この交換は必要なだけの回を続けることができます。 一度、この交換が完成する、クライアントとサーバはセキュリティ協会を設立しました。 このセキュリティ協会は、認証(サーバの、または、互いのクライアント)と保全、そして/または、秘密性のための情報を合わせるのを含めるかもしれません、使用中のメカニズムによって。
The term "security data" here is carefully chosen. The purpose of the security data exchange is to establish a security association, which might not actually include any authentication at all, between the client and the server as described above. For instance, a Diffie-Hellman exchange establishes a secret key, but no authentication takes place. If an FTP server has an RSA key pair but the client does not, then the client can authenticate the server, but the server cannot authenticate the client.
ここの「セキュリティー・データ」という用語は慎重に選ばれています。 セキュリティデータ交換の目的はセキュリティ協会を設立することです、上で説明されるクライアントとサーバの間で。(実際に、協会は全く少しの認証も含んでいません)。 例えば、ディフィー-ヘルマンの交換は秘密鍵を設立しますが、認証は全く行われません。 FTPサーバにはRSA主要な組がありますが、クライアントが持っているというわけではないなら、クライアントはサーバを認証できますが、サーバはクライアントを認証できません。
Once a security association is established, authentication which is a part of this association may be used instead of or in addition to the standard username/password exchange for authorizing a user to connect to the server. A username specified by the USER command is always required to specify the identity to be used on the server.
セキュリティ協会がいったん設立されると、この協会の一部である認証は交換かユーザがサーバに接続するのを認可することへの標準のユーザ名/パスワード交換に加えて使用されるかもしれません。USERコマンドで指定されたユーザ名が、サーバで使用されるためにアイデンティティを指定するのにいつも必要です。
In order to prevent an attacker from inserting or deleting commands on the control stream, if the security association supports integrity, then the server and client must use integrity protection on the control stream, unless it first transmits a CCC command to turn off this requirement. Integrity protection is performed with the MIC and ENC commands, and the 63z reply codes. The CCC command and its reply must be transmitted with integrity protection. Commands and replies may be transmitted without integrity (that is, in the clear or with confidentiality only) only if no security association is established, the negotiated security association does not support integrity, or the CCC command has succeeded.
攻撃者が制御ストリームのときにコマンドを挿入するか、または削除するのを防ぐために、セキュリティ協会が保全をサポートするなら、サーバとクライアントは制御ストリームのときに保全保護を使用しなければなりません、最初にこの要件をオフにするCCCコマンドを伝えない場合。 保全保護はMIC、ENCコマンド、および63z回答コードで実行されます。 保全保護でCCCコマンドとその回答を伝えなければなりません。 セキュリティ協会が全く設立されない場合にだけ、コマンドと回答が保全(すなわち、明確か秘密性だけがある)なしで伝えられるかもしれませんか、交渉されたセキュリティ協会が保全をサポートしないか、またはCCCコマンドは成功しました。
Horowitz & Lunt Standards Track [Page 4] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[4ページ]。
Once the client and server have negotiated with the PBSZ command an acceptable buffer size for encapsulating protected data over the data channel, the security mechanism may also be used to protect data channel transfers.
一度、クライアントとサーバはデータ・チャンネルの上で保護されたデータをカプセル化するために許容できるバッファサイズをPBSZコマンドと交渉したことがあります、また、セキュリティー対策が、データチャンネル転送を保護するのに使用されるかもしれません。
Policy is not specified by this document. In particular, client and server implementations may choose to implement restrictions on what operations can be performed depending on the security association which exists. For example, a server may require that a client authorize via a security mechanism rather than using a password, require that the client provide a one-time password from a token, require at least integrity protection on the command channel, or require that certain files only be transmitted encrypted. An anonymous ftp client might refuse to do file transfers without integrity protection in order to insure the validity of files downloaded.
方針はこのドキュメントによって指定されません。 特に、クライアントとサーバ実装は、存在するセキュリティ協会によって、どんな操作を実行できるかに関する制限を実装するのを選ぶかもしれません。 例えば、サーバは、クライアントがセキュリティー対策でパスワードを使用するよりむしろ認可するのが必要である、クライアントがトークンからワンタイムパスワードを提供するのが必要である、指揮系統の上で少なくとも保全保護を必要とするか、またはあるファイルが暗号化されていた状態で送られるだけであるのを必要とするかもしれません。 アノニマスFTPクライアントは、ファイルの正当性がダウンロードされたのを保障するために保全保護なしでファイル転送をするのを拒否するかもしれません。
No particular set of functionality is required, except as dependencies described in the next section. This means that none of authentication, integrity, or confidentiality are required of an implementation, although a mechanism which does none of these is not of much use. For example, it is acceptable for a mechanism to implement only integrity protection, one-way authentication and/or encryption, encryption without any authentication or integrity protection, or any other subset of functionality if policy or technical considerations make this desirable. Of course, one peer might require as a matter of policy stronger protection than the other is able to provide, preventing perfect interoperability.
次のセクションで説明された依存以外に、機能性のどんな特定のセットも必要ではありません。 これは認証についてなにもにそれを意味します、保全、または、実装が秘密性に要求されます、これらのいずれもしないメカニズムが多く役に立ちませんが。 例えば、これが方針か技術的な問題で望ましくなるなら、メカニズムが、どんな認証も、保全保護も、または機能性の部分集合なしでいかなる他のも唯一の保全が保護、一方向認証、そして/または、暗号化、暗号化であると実装するのは、許容できます。 もちろん、1人の同輩が提供できる状態で政策の問題としてもう片方より強い保護を必要とするかもしれません、完全な相互運用性を防いで。
3. New FTP Commands
3. 新しいFTPコマンド
The following commands are optional, but dependent on each other. They are extensions to the FTP Access Control Commands.
以下のコマンドは、任意ですが、互いに依存しています。 それらはFTP Access Control Commandsへの拡大です。
The reply codes documented here are generally described as recommended, rather than required. The intent is that reply codes describing the full range of success and failure modes exist, but that servers be allowed to limit information presented to the client. For example, a server might implement a particular security mechanism, but have a policy restriction against using it. The server should respond with a 534 reply code in this case, but may respond with a 504 reply code if it does not wish to divulge that the disallowed mechanism is supported. If the server does choose to use a different reply code than the recommended one, it should try to use a reply code which only differs in the last digit. In all cases, the server must use a reply code which is documented as returnable from the command received, and this reply code must begin with the same digit as the recommended reply code for the situation.
一般に、ここに記録された回答コードは必要とされるよりお勧めであるとむしろ記述されています。 意図は最大限の範囲の成功について説明する回答コードと故障モードが存在していますが、サーバがクライアントに提示された情報を制限できるということです。 例えば、サーバは特定のセキュリティー対策を実装するかもしれませんが、それを使用するのに方針制限を抱いてください。 サーバは、この場合534回答コードで応じるべきですが、禁じられたメカニズムがサポートされるのを明かしたくないなら、504回答コードで反応するかもしれません。 サーバが、お勧めのものより異なった回答コードを使用するのを選ぶなら、それは下ケタにおいて異なるだけである回答コードを使用しようとするべきです。 すべての場合では、サーバは受け取られたコマンドによって返却可能であるとして記録される回答コードを使用しなければなりません、そして、この回答コードは状況のためのお勧めの回答コードと同じケタで始まらなければなりません。
Horowitz & Lunt Standards Track [Page 5] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[5ページ]。
AUTHENTICATION/SECURITY MECHANISM (AUTH)
認証/セキュリティー対策(AUTH)
The argument field is a Telnet string identifying a supported
mechanism. This string is case-insensitive. Values must be
registered with the IANA, except that values beginning with "X-"
are reserved for local use.
議論分野はサポートしているメカニズムを特定するTelnetストリングです。 このストリングは大文字と小文字を区別しないです。 「X」と共に始まる値が地方の使用のために予約されるのを除いて、値をIANAに示さなければなりません。
If the server does not recognize the AUTH command, it must respond
with reply code 500. This is intended to encompass the large
deployed base of non-security-aware ftp servers, which will
respond with reply code 500 to any unrecognized command. If the
server does recognize the AUTH command but does not implement the
security extensions, it should respond with reply code 502.
サーバがAUTHコマンドを認識しないなら、それは回答コード500で応じなければなりません。 これが大きい配布しているベースを取り囲むつもりである、非セキュリティ意識する、ftpサーバ。(そのサーバは回答コード500でどんな認識されていないコマンドにも反応するでしょう)。 サーバが、AUTHコマンドを認識しますが、セキュリティが拡大であると実装しないなら、それは回答コード502で応じるべきです。
If the server does not understand the named security mechanism, it
should respond with reply code 504.
サーバが命名されたセキュリティー対策を理解していないなら、それは回答コード504で応じるべきです。
If the server is not willing to accept the named security
mechanism, it should respond with reply code 534.
サーバが命名されたセキュリティー対策を受け入れることを望んでいないなら、それは回答コード534で応じるべきです。
If the server is not able to accept the named security mechanism,
such as if a required resource is unavailable, it should respond
with reply code 431.
サーバが名前付のセキュリティー対策を受け入れることができないなら、まるでaがリソースを必要とするかのようにそのようなものが入手できません、それは回答コード431で応じるべきです。
If the server is willing to accept the named security mechanism,
but requires security data, it must respond with reply code 334.
サーバが命名されたセキュリティー対策を受け入れることを望んでいますが、セキュリティー・データを必要とするなら、それは回答コード334で応じなければなりません。
If the server is willing to accept the named security mechanism,
and does not require any security data, it must respond with reply
code 234.
サーバが命名されたセキュリティー対策を受け入れることを望んで、少しのセキュリティー・データも必要としないなら、それは回答コード234で応じなければなりません。
If the server is responding with a 334 reply code, it may include
security data as described in the next section.
サーバが334回答コードで反応しているなら、それは次のセクションで説明されるようにセキュリティー・データを含むかもしれません。
Some servers will allow the AUTH command to be reissued in order
to establish new authentication. The AUTH command, if accepted,
removes any state associated with prior FTP Security commands.
The server must also require that the user reauthorize (that is,
reissue some or all of the USER, PASS, and ACCT commands) in this
case (see section 4 for an explanation of "authorize" in this
context).
いくつかのサーバが新しい認証を確立するために再発行されるべきAUTHコマンドを許容するでしょう。 受け入れるなら、AUTHコマンドは先のFTP Securityコマンドに関連しているどんな状態も取り除きます。 また、サーバは、ユーザがこの場合再認可するのを(すなわち、USER、PASS、およびACCTコマンドのいくつかかすべてを再発行します)必要としなければなりません(「認可」の説明に関してこのような関係においてはセクション4を見てください)。
Horowitz & Lunt Standards Track [Page 6] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[6ページ]。
AUTHENTICATION/SECURITY DATA (ADAT)
認証/セキュリティー・データ(ADAT)
The argument field is a Telnet string representing base 64 encoded
security data (see Section 9, "Base 64 Encoding"). If a reply
code indicating success is returned, the server may also use a
string of the form "ADAT=base64data" as the text part of the reply
if it wishes to convey security data back to the client.
議論分野はベース64を表すTelnetストリングがセキュリティー・データをコード化したという(セクション9は、「64コード化を基礎づけてください」と見ます)ことです。 また、成功を示す回答コードが返されるなら、セキュリティー・データをクライアントに伝えて戻したいなら、サーバは回答のテキスト部分としてフォーム"ADAT=base64data"のストリングを使用するかもしれません。
The data in both cases is specific to the security mechanism
specified by the previous AUTH command. The ADAT command, and the
associated replies, allow the client and server to conduct an
arbitrary security protocol. The security data exchange must
include enough information for both peers to be aware of which
optional features are available. For example, if the client does
not support data encryption, the server must be made aware of
this, so it will know not to send encrypted command channel
replies. It is strongly recommended that the security mechanism
provide sequencing on the command channel, to insure that commands
are not deleted, reordered, or replayed.
データはどちらの場合も、前のAUTHコマンドで指定されたセキュリティー対策に特定です。 ADATコマンド、および関連回答で、クライアントとサーバは任意のセキュリティプロトコルを行うことができます。 セキュリティデータ交換は意識しているオプション機能が利用可能である両方の同輩のために十分な情報を含まなければなりません。 例えば、クライアントがデータ暗号化をサポートしないなら、サーバをこれを意識するようにしなければならないので、それは暗号化された指揮系統回答を送らないのを知るでしょう。 セキュリティー対策がコマンドが削除もされませんし、再命令もされませんし、再演もされないのを保障するために指揮系統の上の配列を提供することが強く勧められます。
The ADAT command must be preceded by a successful AUTH command,
and cannot be issued once a security data exchange completes
(successfully or unsuccessfully), unless it is preceded by an AUTH
command to reset the security state.
うまくいっているAUTHコマンドでADATコマンドに先行しなければなりません、そして、かつて発行できません。セキュリティ状態をリセットするAUTHコマンドでそれが先行されていない場合データ交換が完了する(首尾よいか不成功)セキュリティ。
If the server has not yet received an AUTH command, or if a prior
security data exchange completed, but the security state has not
been reset with an AUTH command, it should respond with reply code
503.
サーバがまだAUTHコマンドを受け取っていないか、完成していて、セキュリティ状態だけが先のセキュリティデータ交換であるならAUTHコマンドでリセットされていなくて、または回答コード503で応じるなら。
If the server cannot base 64 decode the argument, it should
respond with reply code 501.
サーバが64を基礎づけることができないなら、議論を解読してください、そして、それは回答コード501で応じるべきです。
If the server rejects the security data (if a checksum fails, for
instance), it should respond with reply code 535.
サーバがセキュリティー・データを拒絶するなら(例えば、チェックサムが失敗するなら)、それは回答コード535で応じるべきです。
If the server accepts the security data, and requires additional
data, it should respond with reply code 335.
サーバがセキュリティー・データを受け入れて、追加データを必要とするなら、それは回答コード335で応じるべきです。
If the server accepts the security data, but does not require any
additional data (i.e., the security data exchange has completed
successfully), it must respond with reply code 235.
サーバがセキュリティー・データを受け入れますが、少しの追加データ(すなわち、交換が首尾よく完成したセキュリティー・データ)も必要としないなら、それは回答コード235で応じなければなりません。
If the server is responding with a 235 or 335 reply code, then it
may include security data in the text part of the reply as
specified above.
サーバが235か335回答コードで反応しているなら、それは上で指定されるとして回答のテキスト部分にセキュリティー・データを含むかもしれません。
Horowitz & Lunt Standards Track [Page 7] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[7ページ]。
If the ADAT command returns an error, the security data exchange
will fail, and the client must reset its internal security state.
If the client becomes unsynchronized with the server (for example,
the server sends a 234 reply code to an AUTH command, but the
client has more data to transmit), then the client must reset the
server's security state.
ADATコマンドが誤りを返すと、セキュリティデータ交換は失敗するでしょう、そして、クライアントは国内保安状態をリセットしなければなりません。 クライアントがサーバで非連動するようになるなら(例えば、サーバは234回答コードをAUTHコマンドに送りますが、クライアントには、送るより多くのデータがあります)、クライアントはサーバのセキュリティ状態をリセットしなければなりません。
PROTECTION BUFFER SIZE (PBSZ)
保護バッファサイズ(PBSZ)
The argument is a decimal integer representing the maximum size,
in bytes, of the encoded data blocks to be sent or received during
file transfer. This number shall be no greater than can be
represented in a 32-bit unsigned integer.
議論はファイル転送の間、送るか、または受け取るためにコード化されたデータ・ブロックのバイトで表現される最大サイズを表す10進整数です。 この数は32ビットの符号のない整数でそれほど表すことができないということでしょう。
This command allows the FTP client and server to negotiate a
maximum protected buffer size for the connection. There is no
default size; the client must issue a PBSZ command before it can
issue the first PROT command.
このコマンドで、FTPクライアントとサーバは最大の保護されたバッファサイズに接続を交渉できます。 デフォルトサイズが全くありません。 最初のPROTコマンドを発行できる前にクライアントはPBSZコマンドを発行しなければなりません。
The PBSZ command must be preceded by a successful security data
exchange.
うまくいっているセキュリティデータ交換でPBSZコマンドに先行しなければなりません。
If the server cannot parse the argument, or if it will not fit in
32 bits, it should respond with a 501 reply code.
サーバが議論を分析できないか、または32ビットをうまくはめ込まないなら、それは501回答コードで応じるべきです。
If the server has not completed a security data exchange with the
client, it should respond with a 503 reply code.
サーバがクライアントと共にセキュリティデータ交換を終了していないなら、それは503回答コードで応じるべきです。
Otherwise, the server must reply with a 200 reply code. If the
size provided by the client is too large for the server, it must
use a string of the form "PBSZ=number" in the text part of the
reply to indicate a smaller buffer size. The client and the
server must use the smaller of the two buffer sizes if both buffer
sizes are specified.
さもなければ、サーバは200回答コードで返答しなければなりません。 サーバには、クライアントによって提供されたサイズが大き過ぎるなら、それは、より小さいバッファサイズを示すのに回答のテキスト部分でフォーム「PBSZ=番号」のストリングを使用しなければなりません。 両方のバッファサイズが指定されるなら、クライアントとサーバは2つのバッファサイズについて、より小さいのを使用しなければなりません。
DATA CHANNEL PROTECTION LEVEL (PROT)
データ・チャンネル保護レベル(PROT)
The argument is a single Telnet character code specifying the data
channel protection level.
議論はデータ・チャンネル保護レベルを指定するただ一つのTelnetキャラクタコードです。
This command indicates to the server what type of data channel
protection the client and server will be using. The following
codes are assigned:
このコマンドは、クライアントとサーバがどんなタイプのデータ・チャンネル保護を使用するかをサーバに示します。 以下のコードは割り当てられます:
C - Clear
S - Safe
E - Confidential
P - Private
C(明確なS)金庫E(秘密のP)個人的です。
Horowitz & Lunt Standards Track [Page 8] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[8ページ]。
The default protection level if no other level is specified is
Clear. The Clear protection level indicates that the data channel
will carry the raw data of the file transfer, with no security
applied. The Safe protection level indicates that the data will
be integrity protected. The Confidential protection level
indicates that the data will be confidentiality protected. The
Private protection level indicates that the data will be integrity
and confidentiality protected.
他のレベルが全く指定されないなら、デフォルト保護レベルはClearです。 Clear保護レベルは、データ・チャンネルがファイル転送に関する生データを運ぶのを示します、セキュリティが全く適用されていない状態で。 Safe保護レベルは、データが保護された保全になるのを示します。 Confidential保護レベルは、データが保護された秘密性になるのを示します。 兵士の保護レベルは、データが保全であることを示します、そして、秘密性は保護されました。
It is reasonable for a security mechanism not to provide all data
channel protection levels. It is also reasonable for a mechanism
to provide more protection at a level than is required (for
instance, a mechanism might provide Confidential protection, but
include integrity-protection in that encoding, due to API or other
considerations).
セキュリティー対策がすべてのデータ・チャンネル保護レベルを提供するというわけではないのは、妥当です。 また、メカニズムがレベルにおける必要とされるより多くの保護を提供するのも、妥当です(例えば、メカニズムは保護をConfidentialに供給するかもしれませんが、何らかのAPIのため問題をコード化しながら、それで保全保護を含めてください)。
The PROT command must be preceded by a successful protection
buffer size negotiation.
うまくいっている保護バッファサイズ交渉でPROTコマンドに先行しなければなりません。
If the server does not understand the specified protection level,
it should respond with reply code 504.
サーバが指定された保護レベルを理解していないなら、それは回答コード504で応じるべきです。
If the current security mechanism does not support the specified
protection level, the server should respond with reply code 536.
現在のセキュリティー対策が、指定された保護がレベルであるとサポートしないなら、サーバは回答コード536で反応するべきです。
If the server has not completed a protection buffer size
negotiation with the client, it should respond with a 503 reply
code.
サーバがクライアントとの保護バッファサイズ交渉を終了していないなら、それは503回答コードで応じるべきです。
The PROT command will be rejected and the server should reply 503
if no previous PBSZ command was issued.
PROTコマンドは拒絶されるでしょう、そして、サーバは返答するべきです。503 前のPBSZコマンドを全く発行しなかったなら。
If the server is not willing to accept the specified protection
level, it should respond with reply code 534.
サーバが指定された保護レベルを受け入れることを望んでいないなら、それは回答コード534で応じるべきです。
If the server is not able to accept the specified protection
level, such as if a required resource is unavailable, it should
respond with reply code 431.
まるで必要なリソースが入手できないかのようにサーバが、指定された保護が平らで、そのようであると受け入れることができないなら、それは回答コード431で応じるべきです。
Otherwise, the server must reply with a 200 reply code to indicate
that the specified protection level is accepted.
さもなければ、サーバは、指定された保護レベルが受け入れられるのを示すために200回答コードで返答しなければなりません。
CLEAR COMMAND CHANNEL (CCC)
明確な指揮系統(CCC)
This command does not take an argument.
このコマンドは議論を取りません。
Horowitz & Lunt Standards Track [Page 9] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[9ページ]。
It is desirable in some environments to use a security mechanism
to authenticate and/or authorize the client and server, but not to
perform any integrity checking on the subsequent commands. This
might be used in an environment where IP security is in place,
insuring that the hosts are authenticated and that TCP streams
cannot be tampered, but where user authentication is desired.
いくつかの環境で、その後のコマンドについて検査して、どんな保全も実行するのではなく、クライアントとサーバに認証する、そして/または、権限を与えるのにセキュリティー対策を使用するのが望ましいです。 これはホストを認証して、TCPストリームをいじることができないのを保障して、IPセキュリティが適所にありますが、ユーザー認証が望まれている環境で使用されるかもしれません。
If unprotected commands are allowed on any connection, then an
attacker could insert a command on the control stream, and the
server would have no way to know that it was invalid. In order to
prevent such attacks, once a security data exchange completes
successfully, if the security mechanism supports integrity, then
integrity (via the MIC or ENC command, and 631 or 632 reply) must
be used, until the CCC command is issued to enable non-integrity
protected control channel messages. The CCC command itself must
be integrity protected.
保護のないコマンドがどんな接続のときにも許容されているなら、攻撃者は制御ストリームのときにコマンドを挿入するかもしれません、そして、サーバには、それが無効であったのを知る方法が全くないでしょう。 そのような攻撃、かつてのデータ交換が首尾よく完成するセキュリティを防ぐために、セキュリティー対策が保全をサポートするなら、保全(MICかENCコマンドと、631か632回答を通した)を使用しなければなりません、非保全の保護されたコントロールチャンネルメッセージを可能にするためにCCCコマンドを発行するまで。 CCCコマンド自体は保護された保全であるに違いありません。
Once the CCC command completes successfully, if a command is not
protected, then the reply to that command must also not be
protected. This is to support interoperability with clients which
do not support protection once the CCC command has been issued.
かつてのコマンドが首尾よく完成するCCCであり、また、コマンドが保護されないなら、そのコマンドに関する回答を保護してはいけません。 これは、クライアントと共に相互運用性をサポートするためのものです(いったんCCCコマンドを発行すると、保護をサポートしません)。
This command must be preceded by a successful security data
exchange.
うまくいっているセキュリティデータ交換でこのコマンドに先行しなければなりません。
If the command is not integrity-protected, the server must respond
with a 533 reply code.
コマンドが保全によって保護されていないなら、サーバは533回答コードで反応しなければなりません。
If the server is not willing to turn off the integrity
requirement, it should respond with a 534 reply code.
サーバが保全要件をオフにすることを望んでいないなら、それは534回答コードで応じるべきです。
Otherwise, the server must reply with a 200 reply code to indicate
that unprotected commands and replies may now be used on the
command channel.
さもなければ、サーバは、保護のないコマンドと回答が現在指揮系統の上で使用されるかもしれないのを示すために200回答コードで返答しなければなりません。
INTEGRITY PROTECTED COMMAND (MIC) and CONFIDENTIALITY PROTECTED COMMAND (CONF) and PRIVACY PROTECTED COMMAND (ENC)
保全はコマンド(MIC)を保護しました、そして、秘密性はコマンド(CONF)を保護しました、そして、プライバシーはコマンドを保護しました。(ENC)
The argument field of MIC is a Telnet string consisting of a base
64 encoded "safe" message produced by a security mechanism
specific message integrity procedure. The argument field of CONF
is a Telnet string consisting of a base 64 encoded "confidential"
message produced by a security mechanism specific confidentiality
procedure. The argument field of ENC is a Telnet string
consisting of a base 64 encoded "private" message produced by a
security mechanism specific message integrity and confidentiality
procedure.
MICの議論分野はセキュリティー対策の特定のメッセージの保全手順で出されたベース64のコード化された「金庫」メッセージから成るTelnetストリングです。 CONFの議論分野は64のコード化された「秘密」のメッセージがセキュリティー対策の特定の秘密性手順で作り出したベースから成るTelnetストリングです。 ENCの議論分野は64のコード化された「個人的な」メッセージがセキュリティー対策の特定のメッセージの保全と秘密性手順で作り出したベースから成るTelnetストリングです。
Horowitz & Lunt Standards Track [Page 10] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[10ページ]。
The server will decode and/or verify the encoded message.
サーバは、コード化されたメッセージについて解読する、そして/または、確かめるでしょう。
This command must be preceded by a successful security data
exchange.
うまくいっているセキュリティデータ交換でこのコマンドに先行しなければなりません。
A server may require that the first command after a successful
security data exchange be CCC, and not implement the protection
commands at all. In this case, the server should respond with a
502 reply code.
サーバは、うまくいっているセキュリティデータ交換の後の最初のコマンドがCCCであることが必要であり、保護が全くコマンドであると実装しないかもしれません。 この場合、サーバは502回答コードで反応するべきです。
If the server cannot base 64 decode the argument, it should
respond with a 501 reply code.
サーバが64を基礎づけることができないなら、議論を解読してください、そして、それは501回答コードで応じるべきです。
If the server has not completed a security data exchange with the
client, it should respond with a 503 reply code.
サーバがクライアントと共にセキュリティデータ交換を終了していないなら、それは503回答コードで応じるべきです。
If the server has completed a security data exchange with the
client using a mechanism which supports integrity, and requires a
CCC command due to policy or implementation limitations, it should
respond with a 503 reply code.
サーバがクライアントと共に方針か実装制限のため保全をサポートして、CCCコマンドを必要とするメカニズムを使用することでセキュリティデータ交換を終了したなら、それは503回答コードで応じるべきです。
If the server rejects the command because it is not supported by
the current security mechanism, the server should respond with
reply code 537.
それが現在のセキュリティー対策によってサポートされないのでサーバがコマンドを拒絶するなら、サーバは回答コード537で反応するべきです。
If the server rejects the command (if a checksum fails, for
instance), it should respond with reply code 535.
サーバがコマンドを拒絶するなら(例えば、チェックサムが失敗するなら)、それは回答コード535で応じるべきです。
If the server is not willing to accept the command (if privacy is
required by policy, for instance, or if a CONF command is received
before a CCC command), it should respond with reply code 533.
サーバがコマンドを受け入れることを望んでいないなら(例えば、方針がプライバシーを必要とするか、またはCCCコマンドの前にCONFコマンドを受け取るなら)、それは回答コード533で応じるべきです。
Otherwise, the command will be interpreted as an FTP command. An
end-of-line code need not be included, but if one is included, it
must be a Telnet end-of-line code, not a local end-of-line code.
さもなければ、コマンドはFTPコマンドとして解釈されるでしょう。 行末コードは含まれる必要はありませんが、1つが含まれているなら、それはローカルの行末コードではなく、Telnet行末コードであるに違いありません。
The server may require that, under some or all circumstances, all
commands be protected. In this case, it should make a 533 reply
to commands other than MIC, CONF, and ENC.
サーバは、いくつかかすべての状況によるすべてのコマンドが保護されるのを必要とするかもしれません。 この場合、それは533回答をミック、CONF、およびENC以外のコマンドにするべきです。
4. Login Authorization
4. ログイン承認
The security data exchange may, among other things, establish the identity of the client in a secure way to the server. This identity may be used as one input to the login authorization process.
セキュリティデータ交換はサーバへの安全な方法でクライアントのアイデンティティを特に確立するかもしれません。このアイデンティティは1つの入力としてログイン承認プロセスに使用されるかもしれません。
Horowitz & Lunt Standards Track [Page 11] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[11ページ]。
In response to the FTP login commands (AUTH, PASS, ACCT), the server may choose to change the sequence of commands and replies specified by RFC 959 as follows. There are also some new replies available.
FTPログインコマンド(AUTH、PASS、ACCT)に対応して、サーバは、以下のRFC959によって指定されたコマンドと回答の系列を変えるのを選ぶかもしれません。 また、利用可能ないくつかの新しい回答があります。
If the server is willing to allow the user named by the USER command to log in based on the identity established by the security data exchange, it should respond with reply code 232.
サーバが、セキュリティデータ交換で確立されたアイデンティティに基づいてログインするUSERコマンドで指定されたユーザを許容しても構わないと思っているなら、それは回答コード232で応じるべきです。
If the security mechanism requires a challenge/response password, it should respond to the USER command with reply code 336. The text part of the reply should contain the challenge. The client must display the challenge to the user before prompting for the password in this case. This is particularly relevant to more sophisticated clients or graphical user interfaces which provide dialog boxes or other modal input. These clients should be careful not to prompt for the password before the username has been sent to the server, in case the user needs the challenge in the 336 reply to construct a valid password.
セキュリティー対策が挑戦/応答パスワードを必要とするなら、それは回答コード336でUSERコマンドに応じるべきです。 回答のテキスト部分は挑戦を含むはずです。 クライアントはこの場合パスワードのためのうながす前にユーザへの挑戦を表示しなければなりません。 これは特により洗練されたクライアント、ダイアログボックスを提供するグラフィカルユーザーインターフェースまたは他の様式の入力に関連しています。 ユーザ名をサーバに送る前にこれらのクライアントはパスワードのためのどんなプロンプトにも慎重であるはずがありません、ユーザが有効なパスワードを構成する336回答における挑戦を必要とするといけないので。
5. New FTP Replies
5. 新しいFTP回答
The new reply codes are divided into two classes. The first class is new replies made necessary by the new FTP Security commands. The second class is a new reply type to indicate protected replies.
新しい回答コードは2つのクラスに分割されます。 一流は新しいFTP Securityコマンドで必要にされた新しい回答です。 二等は保護された回答を示す新しい回答タイプです。
5.1. New individual reply codes
5.1. 新しい個々の回答コード
232 User logged in, authorized by security data exchange.
234 Security data exchange complete.
235 [ADAT=base64data]
; This reply indicates that the security data exchange
; completed successfully. The square brackets are not
; to be included in the reply, but indicate that
; security data in the reply is optional.
セキュリティデータ交換で認可されて、232ユーザはログインしました。 234 データ交換が完成するセキュリティ。 235[ADAT=base64data]。 この回答がそれを示す、セキュリティデータ交換。 首尾よく完成されます。 角括弧はそうではありません。 回答に含まれていますが、それを示すために。 回答におけるセキュリティー・データは任意です。
334 [ADAT=base64data]
; This reply indicates that the requested security mechanism
; is ok, and includes security data to be used by the client
; to construct the next command. The square brackets are not
; to be included in the reply, but indicate that
; security data in the reply is optional.
335 [ADAT=base64data]
; This reply indicates that the security data is
; acceptable, and more is required to complete the
; security data exchange. The square brackets
; are not to be included in the reply, but indicate
; that security data in the reply is optional.
334[ADAT=base64data]。 この回答がそれを示す、要求されたセキュリティー対策。 クライアントによって使用されるように、間違いなく、セキュリティー・データを含んでいます。 次のコマンドを構成するために。 角括弧はそうではありません。 回答に含まれていますが、それを示すために。 回答におけるセキュリティー・データは任意です。 335[ADAT=base64data]。 この回答は、セキュリティー・データがそうであることを示します。 許容できる、以上が完全な状態で必要である、。 セキュリティデータ交換。 角括弧。 しかし、回答で含めてはいけなくなってください、示します。 回答におけるそのセキュリティー・データは任意です。
Horowitz & Lunt Standards Track [Page 12] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[12ページ]。
336 Username okay, need password. Challenge is "...."
; The exact representation of the challenge should be chosen
; by the mechanism to be sensible to the human user of the
; system.
オーケーの336ユーザ名必要性パスワード。 「挑戦はそうです」…、」 ; 挑戦の正確な表現は選ばれるべきです。 人間のユーザにとって感じるメカニズム、。 システム。
431 Need some unavailable resource to process security.
431は、セキュリティを処理するために何らかの入手できないリソースを必要とします。
533 Command protection level denied for policy reasons.
534 Request denied for policy reasons.
535 Failed security check (hash, sequence, etc).
536 Requested PROT level not supported by mechanism.
537 Command protection level not supported by security mechanism.
533 コマンド保護レベルは方針のために理由を否定しました。 534要求は方針のために理由を否定しました。 535の失敗したセキュリティチェック(ハッシュ、系列など)。 536はメカニズムによってサポートされなかったPROTレベルを要求しました。 537はセキュリティー対策によってサポートされなかった保護レベルを命令します。
5.2. Protected replies.
5.2. 回答を保護しました。
One new reply type is introduced:
1つの新しい回答タイプを導入します:
6yz Protected reply
6yz Protected回答
There are three reply codes of this type. The first, reply
code 631 indicates an integrity protected reply. The
second, reply code 632, indicates a confidentiality and
integrity protected reply. the third, reply code 633,
indicates a confidentiality protected reply.
このタイプの3つの回答コードがあります。 1番目であり、回答コード631は保全の保護された回答を示します。 2番目(回答コード632)は、秘密性と保全が回答3番目、回答コード633を保護したのを示して、秘密性が回答を保護したのを示します。
The text part of a 631 reply is a Telnet string consisting
of a base 64 encoded "safe" message produced by a security
mechanism specific message integrity procedure. The text
part of a 632 reply is a Telnet string consisting of a base
64 encoded "private" message produced by a security
mechanism specific message confidentiality and integrity
procedure. The text part of a 633 reply is a Telnet string
consisting of a base 64 encoded "confidential" message
produced by a security mechanism specific message
confidentiality procedure.
631回答のテキスト部分はセキュリティー対策の特定のメッセージの保全手順で出されたベース64のコード化された「金庫」メッセージから成るTelnetストリングです。 632回答のテキスト部分は64のコード化された「個人的な」メッセージがセキュリティー対策の特定のメッセージ秘密性と保全手順で作り出したベースから成るTelnetストリングです。 633回答のテキスト部分は64のコード化された「秘密」のメッセージがセキュリティー対策の特定のメッセージ秘密性手順で作り出したベースから成るTelnetストリングです。
The client will decode and verify the encoded reply. How
failures decoding or verifying replies are handled is
implementation-specific. An end-of-line code need not be
included, but if one is included, it must be a Telnet end-
of-line code, not a local end-of-line code.
クライアントは、コード化された回答を解読して、確かめるでしょう。 回答について解読するか、または確かめる失敗がどう扱われるかは、実装特有です。 行末コードは含まれる必要はありませんが、1つが含まれているなら、ローカルの行末コードではなく、回線コードのTelnetエンドであるに違いありません。
A protected reply may only be sent if a security data
exchange has succeeded.
セキュリティデータ交換が成功した場合にだけ、保護された回答を送るかもしれません。
The 63z reply may be a multiline reply. In this case, the
plaintext reply must be broken up into a number of
fragments. Each fragment must be protected, then base 64
63z回答はマルチライン回答であるかもしれません。 この場合、平文回答を多くの断片に終えなければなりません。 各断片は、保護されて、次に、64を基礎づけなければなりません。
Horowitz & Lunt Standards Track [Page 13] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[13ページ]。
encoded in order into a separate line of the multiline
reply. There need not be any correspondence between the
line breaks in the plaintext reply and the encoded reply.
Telnet end-of-line codes must appear in the plaintext of the
encoded reply, except for the final end-of-line code, which
is optional.
マルチライン回答の別々の系列に整然とした状態で、コード化されます。 ラインブレイクの間には、平文回答とコード化された回答に少しの通信もある必要はありません。 telnet行末コードはコード化された回答の平文に現れなければなりません、最終的な行末コードを除いて。(それは、任意です)。
The multiline reply must be formatted more strictly than the
continuation specification in RFC 959. In particular, each
line before the last must be formed by the reply code,
followed immediately by a hyphen, followed by a base 64
encoded fragment of the reply.
RFC959の継続指定より厳密にマルチライン回答をフォーマットしなければなりません。 ベース64があとに続いたすぐにハイフンであとに続く回答コードで最終を形成しなければならない前に特に、各系列は回答の断片をコード化しました。
For example, if the plaintext reply is
例えば、平文であるなら、回答はそうです。
123-First line
Second line
234 A line beginning with numbers
123 The last line
No.123で最終ラインを始める最初に123系列Second系列234A系列
then the resulting protected reply could be any of the
following (the first example has a line break only to fit
within the margins):
次に、結果として起こる保護された回答は以下のいずれであるかもしれません(最初の例には、マージンの中で単に合うラインブレイクがある)も:
631 base64(protect("123-First line\r\nSecond line\r\n 234 A line
631-base64(protect("123-First line\r\n"))
631-base64(protect("Second line\r\n"))
631-base64(protect(" 234 A line beginning with numbers\r\n"))
631 base64(protect("123 The last line"))
631base64、(保護、(「最初に123系列\rの\nSecondはr n234円のA系列631-base64((「最初に123系列\rの\n」)を保護する)631-base64(保護してください(「2番目の系列\rの\n」))631-base64((「数の\r\nで始まる234A系列」)を保護する)631円のbase64を裏打ちします」。(保護、(「123、最終ライン、」、)
631-base64(protect("123-First line\r\nSecond line\r\n 234 A line b"))
631 base64(protect("eginning with numbers\r\n123 The last line\r\n"))
631-base64(保護します(「最初に123系列\rの\nSecondはn234円の\r A系列bを裏打ちする」))631base64(保護します(「数の\r\n123で、最終ライン\r\nをeginningします」))
6. Data Channel Encapsulation
6. データ・チャンネルカプセル化
When data transfers are protected between the client and server (in either direction), certain transformations and encapsulations must be performed so that the recipient can properly decode the transmitted file.
データ転送がクライアントとサーバ(どちらかの方向への)の間に保護されるとき、受取人が適切に伝えられたファイルを解読できるように、ある変換とカプセル化を実行しなければなりません。
The sender must apply all protection services after transformations associated with the representation type, file structure, and transfer mode have been performed. The data sent over the data channel is, for the purposes of protection, to be treated as a byte stream.
表現タイプ、ファイル構造、および転送モードに関連している変換が実行された後に送付者はすべての保護サービスを適用しなければなりません。 データ・チャンネルの上に送られたデータはバイト・ストリームとして扱われることへの保護の目的のためのものです。
When performing a data transfer in an authenticated manner, the authentication checks are performed on individual blocks of the file, rather than on the file as a whole. Consequently, it is possible for
認証された方法でデータ転送を実行するとき、認証チェックは全体でファイルの上でというよりむしろファイルの個々のブロックに実行されます。 その結果、それは可能です。
Horowitz & Lunt Standards Track [Page 14] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[14ページ]。
insertion attacks to insert blocks into the data stream (i.e., replays) that authenticate correctly, but result in a corrupted file being undetected by the receiver. To guard against such attacks, the specific security mechanism employed should include mechanisms to protect against such attacks. Many GSS-API mechanisms usable with the specification in Appendix I, and the Kerberos mechanism in Appendix II do so.
挿入は、データ・ストリーム(すなわち、再生)の中への受信機によって非検出される崩壊したファイルを正しく認証しますが、もたらすブロックを指し込むために攻撃されます。そのような攻撃に用心するなら、使われた特定のセキュリティー対策は、そのような攻撃から守るためにメカニズムを含んでいるはずです。 使用可能な仕様がAppendix Iにあって、Appendix IIにあるケルベロスメカニズムで多くのGSS-APIメカニズムがそうします。
The sender must take the input byte stream, and break it up into blocks such that each block, when encoded using a security mechanism specific procedure, will be no larger than the buffer size negotiated by the client with the PBSZ command. Each block must be encoded, then transmitted with the length of the encoded block prepended as a four byte unsigned integer, most significant byte first.
送付者は、セキュリティー対策の特定の手順を用いることでコード化される場合それぞれのブロックがクライアントによってPBSZコマンドと交渉されたバッファサイズほど、より大きくならないように、入力バイト・ストリームを持って行って、ブロックにそれを壊れさせなければなりません。 各ブロックをコード化しなければならなくて、コード化されたブロックの長さが4バイトとしてprependedされている状態で符号のない整数がその時伝わって、最も重要なバイトは1番目です。
When the end of the file is reached, the sender must encode a block of zero bytes, and send this final block to the recipient before closing the data connection.
ファイルの端に達しているとき、送付者は、バイトがない1ブロックをコード化して、データ接続を終える前に、この最終的なブロックを受取人に送らなければなりません。
The recipient will read the four byte length, read a block of data that many bytes long, then decode and verify this block with a security mechanism specific procedure. This must be repeated until a block encoding a buffer of zero bytes is received. This indicates the end of the encoded byte stream.
次に、受取人は、セキュリティー対策の特定の手順でこのブロックを4バイトの長さを読んで、そんなに多くの長さバイトのデータのブロックを読んで、解読して、確かめるでしょう。 バイトがないバッファをコード化するブロックが受信されるまで、これを繰り返さなければなりません。 これはコード化されたバイト・ストリームの終わりを示します。
Any transformations associated with the representation type, file structure, and transfer mode are to be performed by the recipient on the byte stream resulting from the above process.
表現タイプに関連しているどんな変換、ファイル構造、および転送モードも受取人によって上のプロセスから生じるバイト・ストリームに実行されることです。
When using block transfer mode, the sender's (cleartext) buffer size is independent of the block size.
ブロック転送モードを使用するとき、送付者(cleartext)のバッファサイズはブロック・サイズから独立しています。
The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or APPE command if the current protection level is not at the level dictated by the server's security requirements for the particular file transfer.
現在の保護レベルが特定のファイル転送のためのサーバのセキュリティ要件によって書き取られたレベルにないなら、サーバの意志の回答534対a STOR、STOU、RETR、LIST、NLST、またはAPPEが命令します。
If any data protection services fail at any time during data transfer at the server end (including an attempt to send a buffer size greater than the negotiated maximum), the server will send a 535 reply to the data transfer command (either STOR, STOU, RETR, LIST, NLST, or APPE).
何かデータ保護サービスがサーバ終わりにいつでもデータ転送の間、失敗すると(交渉された最大より大きいバッファサイズを送る試みを含んでいて)、サーバはデータ転送コマンド(STOR、STOU、RETR、LIST、NLST、またはAPPE)に535回答を送るでしょう。
Horowitz & Lunt Standards Track [Page 15] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[15ページ]。
7. Potential policy considerations
7. 潜在的方針問題
While there are no restrictions on client and server policy, there are a few recommendations which an implementation should implement.
制限が全くクライアントとサーバ方針にありませんが、実装が実装するべきであるいくつかの推薦があります。
- Once a security data exchange takes place, a server should require
all commands be protected (with integrity and/or confidentiality),
and it should protect all replies. Replies should use the same
level of protection as the command which produced them. This
includes replies which indicate failure of the MIC, CONF, and ENC
commands. In particular, it is not meaningful to require that
AUTH and ADAT be protected; it is meaningful and useful to require
that PROT and PBSZ be protected. In particular, the use of CCC is
not recommended, but is defined in the interest of
interoperability between implementations which might desire such
functionality.
- 一度、データ交換が取るセキュリティは、保護される(保全、そして/または、秘密性で)ようにすべて命令します、そして、場所、サーバが、必要であるべきであるそれはすべての回答を保護するべきです。 回答はそれらを生産したコマンドへの同じレベルの保護を使用するべきです。 これはミック、CONF、およびENCコマンドの失敗を示す回答を含んでいます。 AUTHとADATが保護されるのが必要であるのは特に、重要ではありません。 PROTとPBSZが保護されるのが必要であるのは、重要であって、役に立ちます。 CCCの使用は、特に、推薦されませんが、そのような機能性を望むかもしれない実装の間の相互運用性のために定義されます。
- A client should encrypt the PASS command whenever possible. It is
reasonable for the server to refuse to accept a non-encrypted PASS
command if the server knows encryption is available.
- 可能であるときはいつも、クライアントはPASSコマンドを暗号化するべきです。 サーバが、暗号化が利用可能であることを知っているなら、サーバが、非暗号化されたPASSコマンドを受け入れるのを拒否するのは、妥当です。
- Although no security commands are required to be implemented, it
is recommended that an implementation provide all commands which
can be implemented, given the mechanisms supported and the policy
considerations of the site (export controls, for instance).
- セキュリティコマンドは全く実装されるのに必要ではありませんが、実装が実装することができるすべてのコマンドを提供するのは、お勧めです、サポートされたメカニズムとサイトの方針問題(例えば、輸出管理)を考えて。
8. Declarative specifications
8. 宣言的な仕様
These sections are modelled after sections 5.3 and 5.4 of RFC 959, which describe the same information, except for the standard FTP commands and replies.
これらのセクションは同じ情報について説明するRFC959のセクション5.3と5.4に倣われます、標準のFTPコマンドと回答を除いて。
8.1. FTP Security commands and arguments
8.1. FTP Securityコマンドと議論
AUTH <SP> <mechanism-name> <CRLF>
ADAT <SP> <base64data> <CRLF>
PROT <SP> <prot-code> <CRLF>
PBSZ <SP> <decimal-integer> <CRLF>
MIC <SP> <base64data> <CRLF>
CONF <SP> <base64data> <CRLF>
ENC <SP> <base64data> <CRLF>
10進整数のAUTH<SP><メカニズム名の fbase64data? jCRLF??CRLF?ADAT?SP??base64data??CRLF?PROT?SP??prot-コード??CRLF?PBSZ?SP????CRLF?MIC?SP??base64data??CRLF?CONF?SP? Ibase64data? 狽bRLF?ENC 唐rP?
<mechanism-name> ::= <string>
<base64data> ::= <string>
; must be formatted as described in section 9
<prot-code> ::= C | S | E | P
<decimal-integer> ::= any decimal integer from 1 to (2^32)-1
<メカニズム名の>:、:= <ストリング><base64data>:、:= <ストリング>。 セクション9<prot-コード>で説明されるようにフォーマットしなければなりません:、:= C| S| E| P<の10進整数の>:、:= どんな10進整数1〜(2^32)-1
Horowitz & Lunt Standards Track [Page 16] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[16ページ]。
8.2. Command-Reply sequences
8.2. コマンド回答系列
Security Association Setup
AUTH
234
334
502, 504, 534, 431
500, 501, 421
ADAT
235
335
503, 501, 535
500, 501, 421
Data protection negotiation commands
PBSZ
200
503
500, 501, 421, 530
PROT
200
504, 536, 503, 534, 431
500, 501, 421, 530
Command channel protection commands
MIC
535, 533
500, 501, 421
CONF
535, 533
500, 501, 421
ENC
535, 533
500, 501, 421
Security-Enhanced login commands (only new replies listed)
USER
232
336
Data channel commands (only new replies listed)
STOR
534, 535
STOU
534, 535
RETR
534, 535
セキュリティAssociation Setup AUTH234 334 502、504、534、431 500、501、421ADAT235 335 503、501、535 500、501、421Data保護交渉は、PBSZ200 503 500、501、421、530PROT200 504、536、503、534、431 500、501、421、530Commandチャンネル保護がMIC535を命令すると命令します; 533 500、501、421CONF535、533 500、501、421ENC535、533 500、501、421のSecurityによって高められたログインはUSER232 336Dataチャネル指令(新しい回答だけが記載した)STOR534、535STOU534、535RETR534、535を命令します(新しい回答だけが記載しました)。
Horowitz & Lunt Standards Track [Page 17] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[17ページ]。
LIST
534, 535
NLST
534, 535
APPE
534, 535
リスト534、535NLST534、535APPE534、535
In addition to these reply codes, any security command can return
500, 501, 502, 533, or 421. Any ftp command can return a reply
code encapsulated in a 631, 632, or 633 reply once a security data
exchange has completed successfully.
これらの回答コードに加えて、どんなセキュリティコマンドも500、501、502、533、または421を返すことができます。 どんなftpコマンドもコードが631、632、または633回答で一度カプセル化した回答にデータ交換が首尾よく完成したセキュリティを返すことができます。
Horowitz & Lunt Standards Track [Page 18] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[18ページ]。
9. State Diagrams
9. 州のダイヤグラム
This section includes a state diagram which demonstrates the flow of authentication and authorization in a security enhanced FTP implementation. The rectangular blocks show states where the client must issue a command, and the diamond blocks show states where the server must issue a response.
このセクションはセキュリティの高められたFTP実装に認証と承認の流れを示す州のダイヤグラムを含んでいます。 矩形ブロックは、ブロックが、サーバがどこで応答を発行しなければならないかを州に示すのをクライアントがコマンドを発行しなければならない州、およびダイヤモンドに示します。
,------------------, USER
__\| Unauthenticated |_________\
| /| (new connection) | /|
| `------------------' |
| | |
| | AUTH |
| V |
| / \ |
| 4yz,5yz / \ 234 |
|<--------< >------------->. |
| \ / | |
| \_/ | |
| | | |
| | 334 | |
| V | |
| ,--------------------, | |
| | Need Security Data |<--. | |
| `--------------------' | | |
| | | | |
| | ADAT | | |
| V | | |
| / \ | | |
| 4yz,5yz / \ 335 | | |
`<--------< >-----------' | |
\ / | |
\_/ | |
| | |
| 235 | |
V | |
,---------------. | |
,--->| Authenticated |<--------' | After the client and server
| `---------------' | have completed authenti-
| | | cation, command must be
| | USER | integrity-protected if
| | | integrity is available. The
| |<-------------------' CCC command may be issued to
| V relax this restriction.
,------------------, ユーザ__\| Unauthenticatedしました。|_________\ | /| (新しい接続) | /| | `------------------' | | | | | | AUTH| | V| | / \ | | 4yz、234 5yz/円| | <、-、-、-、-、-、-、--<>。------------->。 | | \ / | | | \_/ | | | | | | | | 334 | | | V| | | ,--------------------, | | | | 必要性セキュリティー・データ| <--. | | | `--------------------' | | | | | | | | | | ADAT| | | | V| | | | / \ | | | | 4yz、335 5yz/円| | | '<'--------<>。-----------' | | \ / | | \_/ | | | | | | 235 | | V| | ,---------------. | | ,--->| 認証されます。| <、-、-、-、-、-、-、--' | クライアントとサーバの後に| `---------------' | 完成したauthentiを持ってください。| | | 陽イオン、コマンドはそうであるに違いありません。| | ユーザ| 保全で保護にされる| | | 保全は利用可能です。 The| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--'CCCコマンドを発行するかもしれません'| Vはこの規制を緩和します。
Horowitz & Lunt Standards Track [Page 19] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[19ページ]。
| / \
| 4yz,5yz / \ 2yz
|<--------< >------------->.
| \ / |
| \_/ |
| | |
| | 3yz |
| V |
| ,---------------. |
| | Need Password | |
| `---------------' |
| | |
| | PASS |
| V |
| / \ |
| 4yz,5yz / \ 2yz |
|<--------< >------------->|
| \ / |
| \_/ |
| | |
| | 3yz |
| V |
| ,--------------. |
| | Need Account | |
| `--------------' |
| | |
| | ACCT |
| V |
| / \ |
| 4yz,5yz / \ 2yz |
`<--------< >------------->|
\ / |
\_/ |
| |
| 3yz |
V |
,-------------. |
| Authorized |/________|
| (Logged in) |\
`-------------'
| / \ | 4yz、5yz/\2yz| <、-、-、-、-、-、-、--<>。------------->。 | \ / | | \_/ | | | | | | 3yz| | V| | ,---------------. | | | 必要性パスワード| | | `---------------' | | | | | | パス| | V| | / \ | | 4yz、5yz/\2yz| | <、-、-、-、-、-、-、--<>。------------->|、| \ / | | \_/ | | | | | | 3yz| | V| | ,--------------. | | | 必要性アカウント| | | `--------------' | | | | | | ACCT| | V| | / \ | | 4yz、5yz/\2yz| '<'--------<>。------------->| \ / | \_/ | | | | 3yz| V| ,-------------. | | 認可されます。|/________| | (ログインされます) |\ `-------------'
Horowitz & Lunt Standards Track [Page 20] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[20ページ]。
10. Base 64 Encoding
10. 基地64のコード化
Base 64 encoding is the same as the Printable Encoding described in Section 4.3.2.4 of [RFC-1421], except that line breaks must not be included. This encoding is defined as follows.
基地の64コード化はPrintable Encodingがセクション4.3.2で.4[RFC-1421]について説明したのと同じです、ラインブレイクを含んではいけないのを除いて。 このコード化は以下の通り定義されます。
Proceeding from left to right, the bit string resulting from the mechanism specific protection routine is encoded into characters which are universally representable at all sites, though not necessarily with the same bit patterns (e.g., although the character "E" is represented in an ASCII-based system as hexadecimal 45 and as hexadecimal C5 in an EBCDIC-based system, the local significance of the two representations is equivalent).
左から右まで続いて、必ずはありませんが、メカニズム特異的予防ルーチンから生じるビット列は同じビット・パターンですべてのサイトで一般に「表-可能」なキャラクタにコード化されます(例えば、キャラクタ「E」はEBCDICベースのシステムで16進45とした16進C5としたASCIIベースのシステムで代理をされますが、2つの表現のローカルの意味は同等です)。
A 64-character subset of International Alphabet IA5 is used, enabling 6 bits to be represented per printable character. (The proposed subset of characters is represented identically in IA5 and ASCII.) The character "=" signifies a special processing function used for padding within the printable encoding procedure.
6ビットが印刷可能なキャラクタ単位で表されるのを可能にして、国際Alphabet IA5の64文字サブセットが使用されています。 (キャラクタの提案された部分集合は同様にIA5とASCIIで表されます。) キャラクタ「=」は印刷可能なコード化手順の中でそっと歩くのに使用される特別な処理機能を意味します。
The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right across a 24-bit input group output from the security mechanism specific message protection procedure, each 6-bit group is used as an index into an array of 64 printable characters, namely "[A-Z][a- z][0-9]+/". The character referenced by the index is placed in the output string. These characters are selected so as to be universally representable, and the set excludes characters with particular significance to Telnet (e.g., "<CR>", "<LF>", IAC).
4の出力ストリングがキャラクタをコード化したので、コード化プロセスは入力ビットの24ビットのグループを代表します。 24ビットの入力グループ出力の向こう側に左よりセキュリティー対策の特定のメッセージ保護手順よりまっすぐになりかけて、それぞれの6ビットのグループはインデックスとしてすなわち、64の印刷可能なキャラクタ、「[A-Z][a z][0-9]+/」の配列に使用されます。 インデックスによって参照をつけられるキャラクタは出力ストリングに置かれます。 これらのキャラクタは一般に「表-可能」になるように選ばれます、そして、セットは特定の意味でTelnet(例えば、「<CR>」、「<LF>」IAC)までキャラクタを除きます。
Special processing is performed if fewer than 24 bits are available in an input group at the end of a message. A full encoding quantum is always completed at the end of a message. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Output character positions which are not required to represent actual input data are set to the character "=". Since all canonically encoded output is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character.
24ビット未満がメッセージの終わりの入力グループで有効であるなら、特別な処理は実行されます。 完全なコード化量子はいつもメッセージの終わりに完成します。 24入力ビット未満が入力グループで有効であるときに、ゼロ・ビットは、整数の6ビットのグループを結成するために加えられます(右で)。 実際の入力データを表すのに必要でない出力欄はキャラクタ「=」に設定されます。 すべての正準なコード化された出力が整数の八重奏であるので、以下のケースしか起こることができません: (1) 入力をコード化する最終的な量子は24ビットの不可欠の倍数です。 (2) ここで、コード化された出力の最終的なユニットが「=」が全くそっと歩いていない4つのキャラクタの不可欠の倍数になる、入力をコード化する最終的な量子はちょうど8ビットです。 (3) ここで、コード化された出力の最終的なユニットは2人の「=」暫定記号によっていうことになられた2つのキャラクタになるだろうか、入力をコード化する最終的な量子はまさに16ビットです。 ここで、コード化された出力の最終的なユニットは1人の「=」暫定記号によっていうことになられた3つのキャラクタになるでしょう。
Horowitz & Lunt Standards Track [Page 21] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[21ページ]。
Implementors must keep in mind that the base 64 encodings in ADAT, MIC, CONF, and ENC commands, and in 63z replies may be arbitrarily long. Thus, the entire line must be read before it can be processed. Several successive reads on the control channel may be necessary. It is not appropriate to for a server to reject a command containing a base 64 encoding simply because it is too long (assuming that the decoding is otherwise well formed in the context in which it was sent).
作成者はベースのADATの64encodings、ミック、CONF、およびENCが命令して、63zでは、回答が任意に長いかもしれないのを覚えておかなければなりません。 したがって、それを処理できる前に全体の系列を読まなければなりません。 制御チャンネルにおけるいくつかの連続した読書が必要であるかもしれません。 それはそうです。単にそれが長過ぎるので(そうでなければ、解読がそれが送られた文脈で整形式であると仮定して)ベース64コード化を含んでいて、コマンドを拒絶するサーバにおいて、適切ではありません。
Case must not be ignored when reading commands and replies containing base 64 encodings.
ベース64encodingsを含むコマンドと回答を読むとき、ケースを無視してはいけません。
11. Security Considerations
11. セキュリティ問題
This entire document deals with security considerations related to the File Transfer Protocol.
この全体のドキュメントはFile Transferプロトコルに関連するセキュリティ問題に対処します。
Third party file transfers cannot be secured using these extensions, since a security context cannot be established between two servers using these facilities (no control connection exists between servers over which to pass ADAT tokens). Further work in this area is deferred.
これらの拡張子を使用することで第三者ファイル転送を保証できません、2つのサーバの間でこれらの施設を使用することでセキュリティ文脈を確立できないので(どんなコントロール接続もトークンをADATに通過するサーバの間に存在していません)。 この領域でのさらなる仕事は延期されます。
12. Acknowledgements
12. 承認
I would like to thank the members of the CAT WG, as well as all participants in discussions on the "cat-ietf@mit.edu" mailing list, for their contributions to this document. I would especially like to thank Sam Sjogren, John Linn, Ted Ts'o, Jordan Brown, Michael Kogut, Derrick Brashear, John Gardiner Myers, Denis Pinkas, and Karri Balk for their contributions to this work. Of course, without Steve Lunt, the author of the first six revisions of this document, it would not exist at all.
CAT WGのメンバーに感謝申し上げます、" cat-ietf@mit.edu "メーリングリストについての議論のすべての関係者と同様に、このドキュメントへの彼らの貢献のために。 この仕事への彼らの貢献についてサム・シェーグレン、ジョン・リン、テッドTs'o、ジョーダン・ブラウン、マイケルKogut、Derrickブラシーア、ジョン・ガーディナー・マイアーズ、デニス・ピンカス、およびKarri Balkに特に感謝申し上げます。 もちろんスティーブ・ラントのいないこのドキュメントの最初の6つの改正の作者、それは全く存在していないでしょう。
13. References
13. 参照
[TELNET-SEC] Borman, D., "Telnet Authentication and Encryption
Option", Work in Progress.
[telnet SEC] ボーマンと、D.と、「telnet認証と暗号化オプション」は進行中で働いています。
[RFC-1123] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC-1123]ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication Procedures",
RFC 1421, February 1993.
[RFC-1421]リン、J.、「インターネット電子メールのためのプライバシー増進:」 部分I: 「メッセージ暗号化と認証手順」、RFC1421、2月1993日
Horowitz & Lunt Standards Track [Page 22] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[22ページ]。
14. Author's Address
14. 作者のアドレス
Marc Horowitz Cygnus Solutions 955 Massachusetts Avenue Cambridge, MA 02139
マサチューセッツ通りケンブリッジ、マークホロビッツ白鳥座Solutions955MA 02139
Phone: +1 617 354 7688 EMail: marc@cygnus.com
以下に電話をしてください。 +1 7688年の617 354メール: marc@cygnus.com
Horowitz & Lunt Standards Track [Page 23] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[23ページ]。
Appendix I: Specification under the GSSAPI
付録I: GSSAPIの下の仕様
In order to maximise the utility of new security mechanisms, it is desirable that new mechanisms be implemented as GSSAPI mechanisms rather than as FTP security mechanisms. This will enable existing ftp implementations to support the new mechanisms more easily, since little or no code will need to be changed. In addition, the mechanism will be usable by other protocols, such as IMAP, which are built on top of the GSSAPI, with no additional specification or implementation work needed by the mechanism designers.
新しいセキュリティー対策に関するユーティリティを最大にするために、新しいメカニズムがFTPセキュリティー対策としてというよりむしろGSSAPIメカニズムとして実装されるのは、望ましいです。これは、既存のftp実装が、より容易に新しいメカニズムをサポートするのを可能にするでしょう、コードが、まず変えられる必要がないので。 さらに、メカニズムは他のプロトコルで使用可能になるでしょう、IMAPなどのように、メカニズムデザイナーによって必要とされた追加仕様も実装仕事なしで。(IMAPはGSSAPIの上に造られます)。
The security mechanism name (for the AUTH command) associated with all mechanisms employing the GSSAPI is GSSAPI. If the server supports a security mechanism employing the GSSAPI, it must respond with a 334 reply code indicating that an ADAT command is expected next.
GSSAPIを使うすべてのメカニズムに関連しているセキュリティー対策名(AUTHコマンドのための)はGSSAPIです。 サーバが、セキュリティー対策雇用がGSSAPIであるとサポートするなら、334回答コードが、ADATコマンドが次に予想されるのを示していて、それは応じなければなりません。
The client must begin the authentication exchange by calling GSS_Init_Sec_Context, passing in 0 for input_context_handle (initially), and a targ_name equal to output_name from GSS_Import_Name called with input_name_type of Host-Based Service and input_name_string of "ftp@hostname" where "hostname" is the fully qualified host name of the server with all letters in lower case. (Failing this, the client may try again using input_name_string of "host@hostname".) The output_token must then be base 64 encoded and sent to the server as the argument to an ADAT command. If GSS_Init_Sec_Context returns GSS_S_CONTINUE_NEEDED, then the client must expect a token to be returned in the reply to the ADAT command. This token must subsequently be passed to another call to GSS_Init_Sec_Context. In this case, if GSS_Init_Sec_Context returns no output_token, then the reply code from the server for the previous ADAT command must have been 235. If GSS_Init_Sec_Context returns GSS_S_COMPLETE, then no further tokens are expected from the server, and the client must consider the server authenticated.
GSS_Init_をSec_Contextと呼ぶことによって、クライアントは認証交換を始めなければなりません、ベースのHost Serviceの入力_名前_タイプで呼ばれるNameと入力_名前_が結ぶ" ftp@hostname "のGSS_Import_から_名前を出力するために等しい入力_文脈_ハンドル(初めは)、およびtarg_名のために0で「ホスト名」がすべての手紙が小文字にあるサーバの完全に適切なホスト名であるところに向かって。 (これに失敗して、クライアントは" host@hostname "の入力_名前_ストリングを使用することで再試行するかもしれません。) そしてときに出力_トークンはADATコマンドへの議論としてサーバにコード化されて、送られたベース64であるに違いない。 GSS_Init_Sec_ContextがCONTINUE_が必要としたGSS_S_を返すなら、クライアントは、トークンが回答でADATコマンドに返されると予想しなければなりません。 次に、GSS_Init_Sec_Contextへの別の呼び出しにこのトークンを通過しなければなりません。 この場合、GSS_Init_Sec_Contextが出力_トークンを全く返さないなら、前のADATコマンドのためのサーバからの回答コードは235であったに違いありません。 GSS_Init_Sec_Contextが_GSS_S COMPLETEを返すなら、さらなるトークンは全くサーバから予想されません、そして、クライアントはサーバが認証されていると考えなければなりません。
The server must base 64 decode the argument to the ADAT command and pass the resultant token to GSS_Accept_Sec_Context as input_token, setting acceptor_cred_handle to NULL (for "use default credentials"), and 0 for input_context_handle (initially). If an output_token is returned, it must be base 64 encoded and returned to the client by including "ADAT=base64string" in the text of the reply. If GSS_Accept_Sec_Context returns GSS_S_COMPLETE, the reply code must be 235, and the server must consider the client authenticated. If GSS_Accept_Sec_Context returns GSS_S_CONTINUE_NEEDED, the reply code must be 335. Otherwise, the reply code should be 535, and the text of the reply should contain a descriptive error message.
必須ベース64がADATコマンドに議論を解読して、GSS_Accept_Sec_Contextへの結果のトークンを通過するサーバは_トークンを入力しました、アクセプタ_信用_ハンドルをNULLに設定して(「デフォルト資格証明書を使用してください」、)、そして、入力_文脈_ハンドル(初めは)のための0。 出力_トークンを返すなら、それは回答のテキストに"ADAT=base64string"を含んでいることによってクライアントにコード化されて、返されたベース64であるに違いない。 GSS_Accept_Sec_Contextが_GSS_S COMPLETEを返すなら、回答コードは235でなければなりません、そして、サーバはクライアントが認証されていると考えなければなりません。 GSS_Accept_Sec_ContextがCONTINUE_が必要としたGSS_S_を返すなら、回答コードは335でなければなりません。 さもなければ、回答コードは535であるべきです、そして、回答のテキストは描写的であるエラーメッセージを含むべきです。
Horowitz & Lunt Standards Track [Page 24] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[24ページ]。
The chan_bindings input to GSS_Init_Sec_Context and GSS_Accept_Sec_Context should use the client internet address and server internet address as the initiator and acceptor addresses, respectively. The address type for both should be GSS_C_AF_INET. No application data should be specified.
chan_結合は_Sec_ContextをGSS_Initに入力しました、そして、GSS_Accept_Sec_Contextは創始者とアクセプタアドレスとしてそれぞれクライアントインターネットアドレスとサーバインターネットアドレスを使用するはずです。 両方のためのアドレスタイプはGSS_C_AF_INETであるべきです。 アプリケーションデータを全く指定するべきではありません。
Since GSSAPI supports anonymous peers to security contexts, it is possible that the client's authentication of the server does not actually establish an identity.
GSSAPIがセキュリティ文脈に匿名の同輩をサポートするので、クライアントのサーバの認証が実際にアイデンティティを確立しないのは、可能です。
The procedure associated with MIC commands, 631 replies, and Safe file transfers is:
MICコマンド、631の回答、およびSafeファイル転送に関連している手順は以下の通りです。
GSS_Wrap for the sender, with conf_flag == FALSE
送付者、conf_旗の=FALSEとGSS_Wrap
GSS_Unwrap for the receiver
受信機のためのGSS_Unwrap
The procedure associated with ENC commands, 632 replies, and Private file transfers is:
ENCコマンド、632の回答、および兵士のファイル転送に関連している手順は以下の通りです。
GSS_Wrap for the sender, with conf_flag == TRUE
GSS_Unwrap for the receiver
送付者、受信機のためのconf_旗の=TRUE GSS_UnwrapとGSS_Wrap
CONF commands and 633 replies are not supported.
CONFコマンドと633の回答はサポートされません。
Both the client and server should inspect the value of conf_avail to determine whether the peer supports confidentiality services.
ともに、クライアントとサーバは、同輩が、秘密性がサービスであるとサポートするかどうか決定するためにconf_利益の価値を点検するべきです。
When the security state is reset (when AUTH is received a second time, or when REIN is received), this should be done by calling the GSS_Delete_sec_context function.
セキュリティ状態をリセットするとき(もう一度AUTHを受け取るか、またはREINが受け取られているとき)、GSS_Delete_秒_文脈機能を呼ぶことによって、これをするべきです。
Appendix II: Specification under Kerberos version 4
付録II: ケルベロスバージョン4の下における仕様
The security mechanism name (for the AUTH command) associated with Kerberos Version 4 is KERBEROS_V4. If the server supports KERBEROS_V4, it must respond with a 334 reply code indicating that an ADAT command is expected next.
ケルベロスバージョン4に関連しているセキュリティー対策名(AUTHコマンドのための)はケルベロス_V4です。 サーバがケルベロス_V4をサポートするなら、334回答コードが、ADATコマンドが次に予想されるのを示していて、それは応じなければなりません。
The client must retrieve a ticket for the Kerberos principal "ftp.hostname@realm" by calling krb_mk_req(3) with a principal name of "ftp", an instance equal to the first part of the canonical host name of the server with all letters in lower case (as returned by krb_get_phost(3)), the server's realm name (as returned by krb_realmofhost(3)), and an arbitrary checksum. The ticket must then be base 64 encoded and sent as the argument to an ADAT command.
"ftp"の主要な名前でkrb_をmk_req(3)と呼ぶことによって、クライアントはケルベロス主体" ftp.hostname@realm "のチケットを検索しなければならなくて、サーバの正準なホスト名の最初の部分と等しい小文字にあるすべての手紙でインスタンスは(という_krbによって返されるように_phost(3))を手に入れてください、サーバ分野名です。(krb_realmofhost(3))、および任意のチェックサムで返すように。 そしてときにチケットは議論としてADATコマンドにコード化されて、送られたベース64であるに違いない。
Horowitz & Lunt Standards Track [Page 25] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[25ページ]。
If the "ftp" principal name is not a registered principal in the Kerberos database, then the client may fall back on the "rcmd" principal name (same instance and realm). However, servers must accept only one or the other of these principal names, and must not be willing to accept either. Generally, if the server has a key for the "ftp" principal in its srvtab, then that principal only must be used, otherwise the "rcmd" principal only must be used.
"ftp"主要な名がケルベロスデータベースの登録された元本でないなら、クライアントは"rcmd"主要な名(同じインスタンスと分野)に後ろへ下がるかもしれません。 しかしながら、サーバは、唯一の1つかこれらの主要な名前の他を受け入れなければならなくて、受け入れることを望んでいるはずがありません。 一般に、サーバがsrvtabに"ftp"主体のためのキーを持っているなら、その主体だけを使用しなければなりません。さもなければ、"rcmd"主体だけを使用しなければなりません。
The server must base 64 decode the argument to the ADAT command and pass the result to krb_rd_req(3). The server must add one to the checksum from the authenticator, convert the result to network byte order (most significant byte first), and sign it using krb_mk_safe(3), and base 64 encode the result. Upon success, the server must reply to the client with a 235 code and include "ADAT=base64string" in the text of the reply. Upon failure, the server should reply 535.
必須ベース64がADATコマンドに議論を解読して、結果を通過するサーバが_をkrbする、_第req(3)。 サーバが固有識別文字からチェックサムに1つを加えなければならなくて、転向者がネットワークバイトオーダーへの結果である、(最も重要なバイト、1番目)、krb_mk_金庫(3)を使用することでそれに署名してください。そうすれば、ベース64は結果をコード化します。 成功では、サーバは、235コードでクライアントに答えて、回答のテキストに"ADAT=base64string"を含まなければなりません。 失敗では、サーバは535に返答するべきです。
Upon receipt of the 235 reply from the server, the client must parse the text of the reply for the base 64 encoded data, decode it, convert it from network byte order, and pass the result to krb_rd_safe(3). The client must consider the server authenticated if the resultant checksum is equal to one plus the value previously sent.
クライアントがサーバからの235回答を受け取り次第ベース64のコード化されたデータのための回答のテキストを分析して、それを解読して、ネットワークバイトオーダーからそれを変換して、_をkrbするように結果を通過しなければならない、_第金庫(3)。 クライアントは、結果のチェックサムが1つと等しいなら認証されたサーバと値が以前に送られると考えなければなりません。
The procedure associated with MIC commands, 631 replies, and Safe file transfers is:
MICコマンド、631の回答、およびSafeファイル転送に関連している手順は以下の通りです。
krb_mk_safe(3) for the sender
krb_rd_safe(3) for the receiver
送付者krb_のためのkrb_mk_金庫(3)、_受信機のための第金庫(3)
The procedure associated with ENC commands, 632 replies, and Private file transfers is:
ENCコマンド、632の回答、および兵士のファイル転送に関連している手順は以下の通りです。
krb_mk_priv(3) for the sender
krb_rd_priv(3) for the receiver
送付者krb_のためのkrb_mk_priv(3)、_受信機のための第priv(3)
CONF commands and 633 replies are not supported.
CONFコマンドと633の回答はサポートされません。
Note that this specification for KERBEROS_V4 contains no provision for negotiating alternate means for integrity and confidentiality routines. Note also that the ADAT exchange does not convey whether the peer supports confidentiality services.
ケルベロス_V4のためのこの仕様が保全のための代替の手段と秘密性ルーチンを交渉することへの支給を全く含まないことに注意してください。 同輩が、秘密性がサービスであるとサポートするか否かに関係なく、ADAT交換が伝えない注意も。
In order to stay within the allowed PBSZ, implementors must take note that a cleartext buffer will grow by 31 bytes when processed by krb_mk_safe(3) and will grow by 26 bytes when processed by krb_mk_priv(3).
許容PBSZの範囲内にとどまるために、作成者はcleartextバッファがkrb_mk_金庫(3)によって処理されると31バイト成長して、krb_mk_priv(3)によって処理されると26バイト成長するというノートを取らなければなりません。
Horowitz & Lunt Standards Track [Page 26] RFC 2228 FTP Security Extensions October 1997
ホロビッツとラントStandardsはFTPセキュリティ拡大1997年10月にRFC2228を追跡します[26ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published andand distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳をコピーして、他のものに提供するかもしれません、そして、そうでなければ、implmentationを批評するか、それについて説明するか、または補助する派生している作品は全体か一部分配された、準備されて、コピーされて、発行されたandandであるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Horowitz & Lunt Standards Track [Page 27]
ホロビッツとラント標準化過程[27ページ]
一覧
スポンサーリンク
