Network Working Group M. Horowitz
Request for Comments: 2228 Cygnus Solutions
Updates: 959 S. Lunt
Category: Standards Track Bellcore
October 1997
FTP Security Extensions
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
著作権（C）インターネット協会（1997）。全著作権所有。
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.
この文書では、FTPの仕様STD 9、RFC 959、 "ファイル転送プロトコル（FTP）"（1985年10月）に拡張を定義します。これらの拡張機能は、新しいオプションのコマンド、返信、およびファイル転送エンコーディングの導入により制御とデータチャネルの両方で強力な認証、整合性、および機密性を提供します。
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.
この仕様はSTD 9、RFC 959と互換性があることに留意されたいです。
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.
インターネット上で現在STD 9、RFC 959で、所定の位置に定義されたファイル転送プロトコル（FTP）は、（USERとPASSコマンド経由で）サーバにクライアントを認証するためにクリアテキストで渡されたユーザ名とパスワードを使用しています。そのような「匿名」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,
手動で配布されたキーの下に事前に暗号化されたファイルのFTPを経由して1、
2. via electronic mail containing an encoding of a file encrypted under keys which are manually distributed,
手動で配布される鍵の下で暗号化されたファイルのエンコーディングを含む電子メールを介して2.
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の仕様に必要です。
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の認証と暗号化オプションは、（機密性なし）のみ完全性保護のために用意されていませんし、データ・チャネルの保護に対応しません。
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のセキュリティのコンテキストでは、認証は、通常、暗号化技術を使用して、クライアントのIDおよび/または安全な方法でサーバのアイデンティティの確立です。基本的な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.
この用語は通常理解されているようにセキュリティ拡張機能がないと、クライアントの認証は、起こりません。 FTP許可はPASSコマンドの引数として明確にネットワーク上で渡されたパスワード、で達成されます。このパスワードの所有者は、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 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.
FTPのセキュリティの相互作用は、それがAUTHコマンドで使用したいどのようなセキュリティメカニズムサーバーを伝えるクライアントから始まります。サーバは、このメカニズムを受け入れ、このメカニズムを拒否し、または、セキュリティ拡張機能を実装していないサーバーの場合は、完全にコマンドを拒否しますか。それは、サーバが受け入れるものを要求するまで、クライアントは、複数のセキュリティ・メカニズムをしようとします。これは交渉の基本的な形は場所を取ることができます。 （より複雑な交渉が必要な場合は、これは、セキュリティ・メカニズムとして実装されてもよい。）クライアントが解釈するセキュリティ・メカニズムのための追加データで応答しなければならない場合は、サーバーの応答が示されます。何も必要とされない場合、これは通常メカニズムは（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.
ここでの用語「セキュリティデータは、」慎重に選択されます。セキュリティデータ交換の目的は、上記のように、実際にクライアントとサーバー間のすべてのいずれかの認証を、含まれていない場合があり、セキュリティアソシエーションを確立することです。例えば、のDiffie-Hellman交換は、秘密鍵を確立しますが、認証は行われません。 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コマンドで指定したユーザー名は、常にサーバー上で使用するIDを指定する必要があります。
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コマンドが成功した（つまり、明確なまたは唯一の機密性として、ある）整合性なしで送信することができます。
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つのピアは、完璧な相互運用性を防止すること、政策の問題として、他は提供することができるよりも強力な保護が必要な場合があります。
The following commands are optional, but dependent on each other. They are extensions to the FTP Access Control Commands.
次のコマンドはオプションですが、お互いに依存しています。彼らは、FTPアクセス制御コマンドの拡張機能です。
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応答コードで応答することができます。サーバーが、推奨とは異なる応答コードを使用することを選択しない場合、それが唯一の最後の数字が異なる応答コードを使用するようにしてください。すべての場合において、サーバはコマンドを受信からリターナブルとして文書化された応答コードを使用する必要があり、この応答コードは、状況に推奨される応答コードと同じ数字で始まる必要があります。
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.
サーバは、そのような必要なリソースが利用できない場合など、名前のセキュリティ・メカニズムを受け入れることができないなら、それは回答コード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セキュリティコマンドに関連するすべての状態を削除します。サーバはまた、この場合のユーザ再認証（つまり、USER、PASS、およびACCTコマンドの一部または全部を再発行された）（この文脈で「許可」の説明についてはセクション4を参照）ことを必要としなければなりません。
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.
引数フィールドは、（第9章、「ベース64符号化」を参照）、ベース64符号化されたセキュリティデータを表すのTelnet文字列です。成功を示す応答コードが返された場合、それは、クライアントにセキュリティデータを伝えたい場合、サーバーは、応答のテキスト部分としての形式の文字列「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.
ADATコマンドが成功したAUTHコマンドが先行されなければならない、そしてセキュリティの状態をリセットするには、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応答コードで応答している場合、上記の指定され、それは応答のテキスト部分にセキュリティデータを含むことができます。
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コマンドがエラーを返した場合、セキュリティデータ交換は失敗し、クライアントはその内部のセキュリティ状態をリセットする必要があります。クライアントがサーバーと同期しなくなった場合、クライアントは、サーバーのセキュリティ状態をリセットする必要があります（例えば、サーバはAUTHコマンドに234応答コードを送信しますが、クライアントが送信するより多くのデータを持っています）。
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 - プライベート
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.
他のレベルが指定されていない場合、デフォルトの保護レベルはクリアです。クリア保護レベルにはセキュリティが適用されないとデータチャネルは、ファイル転送の生データを運ぶことを示しています。安全保護レベルは、データの整合性が保護されることを示します。機密保護レベルは、データの機密性が保護されることを示します。プライベート保護レベルは、データの整合性と機密性の保護になることを示しています。
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).
セキュリティ・メカニズムは、すべてのデータ・チャネル保護レベルを提供しないことが合理的です。これは、（例えば、メカニズムは、機密保護を提供するかもしれないが、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コマンドは拒否され、以前のPBSZコマンドが発行されなかった場合、サーバは503を返信すべきです。
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)
CLEAR COMMAND CHANNEL（CCC）
This command does not take an argument.
このコマンドは引数を取りません。
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.
これは、認証および/またはクライアントとサーバーを承認、しかし、後続のコマンドで確認する任意の整合性を実行しないように、セキュリティ・メカニズムを使用するために、いくつかの環境では望ましいです。これは、IPセキュリティはホストが認証され、TCPストリームが改ざんすることはできませんが、ユーザー認証が望まれることをされていることを保証する、所定の位置にある環境で使用される可能性があります。
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.
保護されていないコマンドは任意の接続で許可されている場合、攻撃者が制御ストリームにコマンドを挿入することができ、サーバは、それが無効であることを知る方法はありません。セキュリティ・メカニズムは、整合性をサポートしている場合、セキュリティデータ交換は、正常に完了したら、CCCコマンドを有効にするために発行されるまで（MICまたはENCコマンド、および631または632リプライを経由して）整合性が、使用されている必要があり、その後、このような攻撃を防ぐために非整合性は、制御チャネルメッセージを保護しました。 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)
完全性を保護COMMAND（MIC）および機密PROTECTED命令（CONF）およびプライバシーPROTECTED命令（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文字列です。
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.
サーバは（CONFコマンドがCCCコマンドの前に受信された場合、プライバシーは、例えば、ポリシーによって要求、またはされている場合）コマンドを受け入れることを望んでいないなら、それは回答コード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.
サーバーは、一部またはすべての状況下で、すべてのコマンドが保護される、ことを要求することができます。この場合、MIC、CONF、およびENC以外のコマンドへの533応答を行う必要があります。
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.
セキュリティデータ交換は、とりわけ、サーバへのセキュアな方法でクライアントのアイデンティティを確立することができます。このIDは、ログイン承認プロセスへの1つの入力として使用することができます。
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）に応答して、サーバは、次のようにRFC 959で指定されたコマンドと応答の順序を変更することもできます。利用できるいくつかの新しい返信もあります。
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応答で挑戦を必要とする場合には、ユーザー名は、サーバーに送信される前にパスワードの入力を要求しないように注意する必要があります。
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セキュリティコマンドで必要な作られた新しい返信です。第二のクラスは、保護された応答を示すために、新しい回答タイプです。
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]。この応答は、セキュリティデータがあることを示します。許容可能な、そしてより多くを完了するために必要とされます。セキュリティデータ交換。角括弧;返信に含まれていないですが、示しています。返信にそのセキュリティデータはオプションです。
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コマンド保護レベルは、セキュリティ・メカニズムによってサポートされていません。
One new reply type is introduced:
一つの新しい回答タイプが導入されています。
6yz Protected reply
6yz保護された回答
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つの応答コードがあります。最初は、応答コード631は、完全性を保護応答を示しています。第二は、コード632を返信、機密性と完全性保護された応答を示します。第三に、コード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 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.
63Zの応答は複数行リプライかもしれません。この場合、平文返信がフラグメントの数に分割する必要があります。各断片は、次いで64は複数行応答の別々の行に順に符号化されたベースと、保護されなければなりません。平文返信に改行とエンコードされた応答の間の任意の対応があるわけではありません。 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.
複数行の応答は、特にRFC 959で継続仕様より厳密にフォーマットする必要があり、最後の前の各ラインは応答コードで形成されなければならない、応答のベース64符号化された断片が続く、ハイフン直後。
For example, if the plaintext reply is
例えば、平文返信がある場合
123-First line Second line 234 A line beginning with numbers 123 The last line
123ファーストラインセカンドライン234は、行が番号123最後の行で始まります
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"))
631のBASE64（保護（123ファーストラインの\ r \ n "123ファーストラインの\ R \ nSecondライン\器R \ nは234行631-BASE64（（保護" "保護（））631-BASE64の（" 第二線\ R \ nを234番号で始まる行を "））631-BASE64（（保護" \ R \ n "））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 631のBASE64（（ "数字とeginning \ R \ N123最後の行の\ r \ n" を保護する））（（ "123・ファーストラインの\ R \ nSecondライン\ rをする\ n 234ラインB"）を保護します）
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 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.
認証された方法でデータ転送を行う場合、認証チェックはなく、全体としてのファイルよりも、ファイルの各ブロックで実行されます。挿入攻撃が正しく認証されたデータストリーム（即ち、リプレイ）にブロックを挿入するが、破損したファイルが受信機によって未検出さをもたらすようにするため、結果として、それが可能です。このような攻撃を防ぐために、用いられる特定のセキュリティ・メカニズムは、そのような攻撃から保護するためのメカニズムを含むべきです。多くの付録Iでの仕様で使用可能なGSS-APIメカニズム、および付録IIでのKerberosメカニズムがそう。
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バイトの符号なし整数として付加符号化ブロックの長さは、最上位バイトで送信、符号化されなければなりません。
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.
ファイルの終わりに到達したとき、送信者はゼロバイトのブロックを符号化し、データ接続を閉じる前に、受信者にこの最終ブロックを送信しなければなりません。
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.
ブロック転送モードを使用する場合、送信者（平文）バッファサイズは、ブロックサイズとは無関係です。
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.
現在の保護レベルは、特定のファイル転送のためのサーバーのセキュリティ要件によって決定されるレベルではない場合、サーバはSTOR、STOU、RETR、LIST、NLST、またはAPPEコマンドに534を返信させていただきます。
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).
すべてのデータ保護サービスは、（交渉さ最大値よりも大きいバッファサイズを送信しようとする試みを含む）は、サーバー側でのデータ転送中に任意の時点で失敗した場合、サーバーは、データ転送コマンドに535応答を送信します（どちらかSTOR、STOU、 RETR、LIST、NLST、またはAPPE）。
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.
- セキュリティデータ交換が行われると、サーバはすべてのコマンドは、（整合性および/または機密性）保護される必要がなければならない、そしてそれはすべての返信を保護する必要があります。回答は、それらを生成コマンドと同じレベルの保護を使用する必要があります。これはMIC、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).
- 何のセキュリティコマンドを実装する必要がありませんが、実装を実現することができるすべてのコマンドを提供していること、それが（例えば、輸出規制）サポートメカニズムとサイトのポリシーの考慮事項与えられ、推奨されます。
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.
ここでは、標準のFTPコマンドと応答を除いて、同じ情報を記述セクション5.3およびRFC 959の5.4、後にモデル化されています。
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>
<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
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
LIST
534, 535
NLST
534, 535
APPE
534, 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.
これらの応答コードに加えて、任意のセキュリティコマンドは、セキュリティデータ交換が正常に完了した後、任意のFTPコマンド631、632、または633応答でカプセル化された応答コードを返すことができ500、501、502、533を返す、または421ことができます。
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.
| / \
| 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) |\
`-------------'
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符号化は、[RFC-1421]のセクション4.3.2.4に記載の印刷可能なエンコーディングと同じです。以下のように、このエンコードが定義されます。
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」はASCIIで表現されたが、左から右に進むと、メカニズムから生じたビット列が特定の保護ルーチンは、同じビットパターン（例えば、と必ずしもそうではないが、すべてのサイトで普遍的に表現されている文字にエンコードされますベースシステム進数45のようにEBCDICベースのシステムにおける進C5のように、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.
国際アルファベットIA5の64文字のサブセットは、印刷可能な文字ごとに表現する6ビットを可能に用いられます。 （文字の提案されたサブセットは、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ビットのグループは、[AZ] [0 64印刷可能文字、すなわち「[AZ]の配列へのインデックスとして使用されます-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）符号化入力の最終量子が正確に8ビットであり、NO「=」パディングと4つの文字の整数倍であろう。ここで、符号化された出力の最終的なユニットは、2つの「=」パディング文字に続く2つの文字であるか、または（3）符号化入力の最終的な量子は正確に16ビットです。ここでは、エンコードされた出力の最終単位は1「=」パディング文字が続く3つの文字になります。
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、MIC、CONF、およびENCでベース64のエンコーディングのコマンドことを心に留めておく必要があり、63Z回答に任意の長さであってもよいです。それが処理される前にこのように、行全体を読まなければなりません。いくつかの連続が必要であるかもしれない制御チャネル上で読み取ります。それは長すぎるため、サーバは、単にベース64符号化を含むコマンドを拒否するため（デコードがさもなければよく、それが送信されたコンテキストに形成されていると仮定して）に適切ではありません。
Case must not be ignored when reading commands and replies containing base 64 encodings.
ベース64件のエンコーディングを含むコマンドと応答を読み込むときにケースを無視してはいけません。
This entire document deals with security considerations related to the File Transfer Protocol.
この文書全体では、ファイル転送プロトコルに関連するセキュリティ上の考慮事項を扱います。
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.
セキュリティコンテキストは、これらの施設（何の制御接続は、ADATトークンに合格する以上のサーバー間に存在しない）を使用して2台のサーバー間で確立することができないため、サードパーティ製のファイル転送は、これらの拡張機能を使用して保護することはできません。この分野での更なる作業は延期されます。
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-ietf@mit.edu」メーリングリストで議論にCAT WGのメンバーだけでなく、すべての参加者に感謝したいと思います。私は特にこの作品への貢献のためにサムシェーグレン、ジョン・リン、テッドTs'oさん、ヨルダンブラウン、マイケルKogut、デリックBrashear、ジョン・ガーディナーマイヤーズ、デニスピンカス、およびカリボークに感謝したいと思います。もちろん、スティーブ・ラント、このドキュメントの最初の6本の改訂版の作者せずに、それは全く存在しなかったでしょう。
[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.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[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：メッセージの暗号化と認証手順"、RFC 1421、1993年2月。
Marc Horowitz Cygnus Solutions 955 Massachusetts Avenue Cambridge, MA 02139
マーク・ホロウィッツシグナスソリューションズ955マサチューセッツアベニューケンブリッジ、MA 02139
Phone: +1 617 354 7688 EMail: marc@cygnus.com
電話：+1 617 354 7688 Eメール：marc@cygnus.com
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.
新しいセキュリティ・メカニズムの効用を最大化するためには、新しいメカニズムはGSSAPIメカニズムとしてではなく、FTPのセキュリティメカニズムとして実装されることが望ましいです。ほとんど、あるいはまったくコードを変更する必要がありますので、これは、より簡単に新しいメカニズムをサポートするために、既存のFTPの実装を可能にします。また、機構は、機構設計によって不要追加の仕様や実装作業と、GSSAPIの上に構築されるようにIMAPなどの他のプロトコルによって使用可能であろう。
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を利用したセキュリティ・メカニズムをサポートしている場合、それはADATコマンドが次の期待されていることを示す334応答コードで応答しなければなりません。
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.
クライアントは、（最初は）input_context_handleのために0を渡し、もしGSS_Init_sec_contextを呼び出すことにより、認証情報の交換を開始しなければならない、とGSS_Import_Nameからoutput_nameに等しいtarg_nameは、ホストベースのサービスのinput_name_typeと「ホスト名が」ある「のftp @ホスト名」のinput_name_stringと呼ばれます小文字のすべての文字とサーバーの完全修飾ホスト名。 （これを失敗すると、クライアントは、「ホスト@ホスト名」のinput_name_stringを使用して再度試してください。）のoutput_tokenはその後、ベース64エンコードとADATコマンドの引数としてサーバに送信されなければなりません。もしGSS_Init_sec_contextがGSS_S_CONTINUE_NEEDEDを返す場合、クライアントは、トークンがADATコマンドへの応答で返されることを期待しなければなりません。このトークンは、その後、もしGSS_Init_sec_contextへの別の呼び出しに渡す必要があります。もしGSS_Init_sec_contextは何のoutput_tokenを返していない場合もしGSS_Init_sec_contextがGSS_S_COMPLETEを返した場合この場合は、その後、前のADATコマンドに対するサーバからの応答コードが235となっている必要があり、それ以上のトークンは、サーバから期待されていない、そしてクライアントは、サーバが認証考慮する必要があります。
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.
サーバーは、ADATコマンドに引数64のデコードをベースと入力トークンとしてのgss_accept_sec_contextに生じたトークンを渡し、（「使用既定の資格情報」のための）NULLにacceptor_cred_handleを設定し、input_context_handleのための0（最初は）必要があります。たoutput_tokenが返された場合、それは64を符号化して、返信のテキストで「ADAT = base64string」を含むことにより、クライアントに返さベースでなければなりません。場合gss_accept_sec_contextはGSS_S_COMPLETEを返す場合、応答コードが235でなければならず、サーバが認証されたクライアントを考慮しなければなりません。場合gss_accept_sec_contextはGSS_S_CONTINUE_NEEDEDを返す場合、応答コードは、そうでなければ335でなければならず、応答コードが535であるべきであり、応答のテキストは、説明のエラーメッセージを含むべきです。
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.
もしGSS_Init_sec_contextとのgss_accept_sec_contextにchan_bindings入力は、それぞれ、イニシエータとアクセプタアドレスなどのクライアントのインターネットアドレスとサーバのインターネットアドレスを使用する必要があります。両方のアドレスタイプは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件の回答、および安全なファイル転送に関連した手順は次のとおりです。
GSS_Wrap for the sender, with conf_flag == FALSE
conf_flagと送信者のためにGSS_Wrap、== FALSE
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_flagと送信者のためにGSS_Wrap、== TRUEはgss_unwrap
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_availの値を検査する必要があります。
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_sec_context関数を呼び出すことにより行われるべきです。
Appendix II: Specification under Kerberos version 4
付録II：Kerberosバージョン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.
Kerberosバージョン4に関連付けられたセキュリティ機構名（AUTHコマンドの）KERBEROS_V4あります。サーバがKERBEROS_V4をサポートしている場合、それはADATコマンドが次の期待されていることを示す334応答コードで応答しなければなりません。
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）を呼び出すことにより、すべての文字とサーバーの正規ホスト名の最初の部分に等しいインスタンスをKerberosプリンシパル「ftp.hostname@realm」のチケットを取得する必要があります小文字（krb_get_phost（3）によって返される）、サーバーのレルム名（krb_realmofhost（3）によって返される）、及び任意のチェックサム。チケットは、その後64は、符号化及びADATコマンドの引数として送信ベースでなければなりません。
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」のプリンシパル名がKerberosデータベースに登録主要でない場合、クライアントは「RCMD」プリンシパル名（同じインスタンスとレルム）に頼ることがあります。ただし、サーバーは、これらの主要な名前のどちらか一方だけを受け入れる必要があり、どちらか受け入れることを望んであってはなりません。サーバがその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コマンドの引数をベースと、（3）krb_rd_reqする結果に合格しなければなりません。サーバは、バイト順序（最上位バイト）をネットワークに結果を変換し、オーセンティケータからチェックサムに1を追加し、krb_mk_safe（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_rd_safeする（3）に結果を渡します。その結果、チェックサムが1プラス以前に送信された値と等しい場合、クライアントは、認証サーバーを考慮する必要があります。
The procedure associated with MIC commands, 631 replies, and Safe file transfers is:
MICコマンド、631件の回答、および安全なファイル転送に関連した手順は次のとおりです。
krb_mk_safe(3) for the sender krb_rd_safe(3) for the receiver
受信機の送信者krb_rd_safeためkrb_mk_safe（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_rd_privためkrb_mk_priv（3）（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.
KERBEROS_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内にとどまるためには、実装者はkrb_mk_safe（3）によって処理されるとクリアテキストバッファは31バイトで成長することに注意しなければならないとkrb_mk_priv（3）によって処理された際に26バイトで成長します。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1997). All Rights Reserved.
著作権（C）インターネット協会（1997）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピー、公表andand配布することができることを説明したり、そのimplmentationを支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。