[要約] RFC 2228はFTPセキュリティ拡張に関する規格であり、FTPセッションのセキュリティを向上させるための機能を提供します。目的は、FTPプロトコルのセキュリティを強化し、データの機密性と整合性を確保することです。
Network Working Group M. Horowitz
Request for Comments: 2228 Cygnus Solutions
Updates: 959 S. Lunt
Category: Standards Track Bellcore
October 1997
FTP Security Extensions
FTPセキュリティ拡張機能
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（c）The Internet Society（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（Integrity Protected Command）、CONF（Conf ConfritionAlities Protected Command）、および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）は、クリアテキストで渡されたユーザー名とパスワードを使用して、クライアントをサーバーに認証する（ユーザーとパスコマンドを介して）使用します。「匿名」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. Kerberosを使用するために強化された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プロトコル内で一貫した方法でサポートされ、既存のセキュリティインフラストラクチャとテクノロジーを活用する必要があります。これらのセキュリティサービスを相互運用可能な方法でプロトコルに導入する場合、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]を定義しています。
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.
許可は、ログインのユーザーを検証するプロセスです。基本的な認証プロセスには、ユーザー、パス、および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認証はパスワードで達成され、パスコマンドへの引数としてクリアされたネットワークに渡されます。このパスワードの所有者は、ユーザーコマンドに名前が付けられたユーザーとしてファイルを転送することを許可されていると想定されていますが、クライアントの身元は安全に確立されることはありません。
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
FTPセキュリティインタラクションは、クライアントがサーバーに、AUTHコマンドで使用したいセキュリティメカニズムを伝えることから始まります。サーバーは、このメカニズムを受け入れるか、このメカニズムを拒否するか、セキュリティ拡張機能を実装していないサーバーの場合、コマンドを完全に拒否します。クライアントは、サーバーが受け入れるものを要求するまで、複数のセキュリティメカニズムを試すことができます。これにより、初歩的な形式の交渉が行われます。（より複雑な交渉が必要な場合、これはセキュリティメカニズムとして実装される場合があります。）サーバーの返信は、クライアントが追加のデータで応答する必要があるかどうかを示します。
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コマンドで指定）が、トークンや1回限りのパスワードシステムなど、異なる方法で解釈されることを意味します。
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 Exchangeは秘密の鍵を確立しますが、認証は行われません。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.
セキュリティ協会が確立されると、この協会の一部である認証は、ユーザーがサーバーに接続することを許可するための標準のユーザー名/パスワード交換の代わりに、またはそれに加えて使用できます。ユーザーコマンドによって指定されたユーザー名は、サーバーで使用する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コマンドとその返信は、整合性保護を伴う必要があります。セキュリティ協会が確立されていない場合にのみ、整合性（つまり、明確または機密性のみでのみ）なしでコマンドと返信が送信される場合があります。
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.
ポリシーはこのドキュメントで指定されていません。特に、クライアントとサーバーの実装は、存在するセキュリティ協会に応じて実行できる操作を制限することを選択する場合があります。たとえば、サーバーは、クライアントがパスワードを使用するのではなく、セキュリティメカニズムを介してクライアントを承認することを要求する場合があります。クライアントがトークンから1回限りのパスワードを提供するか、コマンドチャネルで少なくとも整合性保護を必要とするか、特定のファイルが必要な場合があります。暗号化されただけで送信されます。匿名の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.
次のセクションで説明されている依存関係を除き、特定の機能セットは必要ありません。これは、実装には認証、整合性、または機密性のいずれも必要ないことを意味しますが、これらのいずれもそれほど役に立たないメカニズムはあまり役に立たないことを意味します。たとえば、メカニズムが整合性保護、一元配置認証および/または暗号化、認証または整合性保護なしの暗号化、またはポリシーまたは技術的な考慮事項がこれを望ましい場合に機能のその他のサブセットのみを実装することは許容されます。もちろん、一方のピアは、他のピアが他のピアが提供できるよりも強力な保護の問題として必要とするかもしれないため、完全な相互運用性を防ぎます。
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.
サーバーが認証コマンドを認識しない場合、返信コード500で応答する必要があります。これは、非セキュリティ認識FTPサーバーの大規模な展開ベースを含むことを目的としています。サーバーがAUTHコマンドを認識しているが、セキュリティ拡張機能を実装していない場合、Reply Code 502で応答する必要があります。
If the server does not understand the named security mechanism, it should respond with reply code 504.
サーバーが指定されたセキュリティメカニズムを理解していない場合、Reply Code 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).
一部のサーバーでは、新しい認証を確立するために、認証コマンドを再発行できます。認証コマンドは、受け入れられた場合、以前のFTPセキュリティコマンドに関連する状態を削除します。また、サーバーは、この場合、ユーザーがユーザーの一部またはすべてを再発行、パス、および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.
引数フィールドは、ベース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.
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.
サーバーがまだ認証コマンドを受信していない場合、または以前のセキュリティデータ交換が完了したが、セキュリティ状態が認証コマンドでリセットされていない場合、Reply Code 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コマンドがエラーを返した場合、セキュリティデータ交換は失敗し、クライアントは内部セキュリティ状態をリセットする必要があります。クライアントがサーバーで無効化されていない場合（たとえば、サーバーは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.
引数は、ファイル転送中に送信または受信されるエンコードされたデータブロックの最大サイズ、バイト内の最大サイズを表す小数整数です。この数値は、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 = number」の文字列を使用して、バッファサイズが小さくなる必要があります。クライアントとサーバーは、両方のバッファサイズが指定されている場合、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)
クリアコマンドチャネル（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コマンドが発行されるまで（マイクまたはENCコマンド、および631または632の返信を介して（マイクまたは631または632の返信）、整合性（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)
Integrity Protected Command（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文字列です。
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つが含まれている場合は、ローカルエンドオブラインコードではなく、テルネットエンドオブラインコードである必要があります。
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.
サーバーが、ユーザーコマンドによって名前が付けられたユーザーが、セキュリティデータ交換によって確立されたIDに基づいてログインすることを喜んで許可する場合、返信コード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を使用してユーザーコマンドに応答する必要があります。返信のテキスト部分にはチャレンジが含まれている必要があります。この場合、パスワードを求める前に、クライアントはユーザーに課題を表示する必要があります。これは、ダイアログボックスまたはその他のモーダル入力を提供する、より洗練されたクライアントまたはグラフィカルなユーザーインターフェイスに特に関連しています。ユーザーが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セキュリティコマンドによって必要な新しい返信です。2番目のクラスは、保護された返信を示す新しい返信タイプです。
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.
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.
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.
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は返信を保護しました
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は、整合性保護された返信を示します。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つが含まれている場合は、ローカルエンドオブラインコードではなく、テルネットエンドオブラインコードである必要があります。
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です
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.
マルチラインの応答は、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(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"))
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.
サーバーは、特定のファイル転送のサーバーのセキュリティ要件によって現在の保護レベルが決定されていない場合、534がStor、stou、ret、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).
サーバーエンドでのデータ転送中にいつでも障害が発生した場合（交渉最大値よりも大きいバッファサイズを送信する試みを含む）、サーバーはデータ転送コマンドに535の返信を送信します（Stor、stou、ret、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.
- クライアントは、可能な限りパスコマンドを暗号化する必要があります。サーバーが暗号化が利用可能であることを知っている場合、サーバーが暗号化されていないパスコマンドの受け入れを拒否することは合理的です。
- 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コマンドと返信を除き、同じ情報を説明するRFC 959のセクション5.3および5.4をモデルにしています。
8.1. FTP Security commands and arguments
8.1. FTPセキュリティコマンドと引数
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
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
セキュリティ協会のセットアップAUTH 234 334 502、504、534、431 500、501、421 Adat 235 335 503、501、535 500、501、421データ保護交渉コマンドPBSZ 200 503 500、501、421、530 Prot 200 504、5366、5366、503、534、431 500、501、421、530コマンドチャネル保護コマンドMIC 535、533 500、501、421 Conf 535、533 500、501、421 Enc 535、533 500、501、421セキュリティ強化ログインコマンド（リストされている新しい返信のみ）ユーザー232 336データチャネルコマンド（リストされている新しい返信のみ）STOR 534、535 STOU 534、535 RET 534、535
LIST 534, 535 NLST 534, 535 APPE 534, 535
リスト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.
これらの返信コードに加えて、セキュリティコマンドは500、501、502、533、または421を返すことができます。FTPコマンドは、セキュリティデータ交換が正常に完了すると、631、632、または633の返信にカプセル化された返信コードを返すことができます。
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で表されますが-ebcdicベースのシステムにおける16進数として、および16進数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.
International Alphabet 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ビットグループは、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ビットの積分倍です。ここで、エンコードされた出力の最終単位は、「=」パディングなしの4文字の積分倍数になります。（2）エンコード入力の最終量は正確に8ビットです。ここで、エンコードされた出力の最終単位は、2つの文字に続いて2つの「=」パディング文字、または（3）エンコード入力の最終量は正確に16ビットです。ここで、エンコードされた出力の最終単位は3文字に続いて1つの「=」パディング文字が続きます。
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エンコーディングがarbitrarily意的に長い場合があることに留意する必要があります。したがって、回線全体を処理する前に読み取る必要があります。制御チャネル上のいくつかの連続した読み取りが必要になる場合があります。サーバーが、長すぎるという理由だけでベース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.
これらの機能を使用して2つのサーバー間でセキュリティコンテキストを確立できないため、サードパーティファイルの転送はこれらの拡張機能を使用して保護できません（Adatトークンを通過するサーバー間に制御接続はありません）。この分野でのさらなる作業が延期されます。
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」メーリングリストに関する議論のすべての参加者に感謝します。特に、サム・シェーグレン、ジョン・リン、テッド・ツェー、ジョーダン・ブラウン、マイケル・コグート、デリック・ブラシア、ジョン・ガーディナー・マイヤーズ、デニス・ピンカス、カリ・バークにこの仕事に貢献してくれたことに感謝します。もちろん、この文書の最初の6つの改訂の著者であるスティーブ・ラントがいなければ、まったく存在しません。
[TELNET-SEC] Borman, D., "Telnet Authentication and Encryption Option", Work in Progress.
[telnet-sec]ボーマン、D。、「テルネット認証と暗号化オプション」、進行中の作業。
[RFC-1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC-1123] Braden、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] Linn、J。、「インターネット電子メールのプライバシー強化：パートI：メッセージ暗号化と認証手順」、RFC 1421、1993年2月。
Marc Horowitz Cygnus Solutions 955 Massachusetts Avenue Cambridge, MA 02139
マークホロウィッツシグナスソリューション955マサチューセッツアベニューケンブリッジ、マサチューセッツ州02139
Phone: +1 617 354 7688
EMail: 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.
新しいセキュリティメカニズムの有用性を最大化するために、FTPセキュリティメカニズムとしてではなく、GSSAPIメカニズムとして新しいメカニズムを実装することが望ましい。これにより、既存のFTP実装は、コードを変更する必要がほとんどないかどうかを変更する必要がないため、新しいメカニズムをより簡単にサポートできるようになります。さらに、メカニズムは、メカニズム設計者が必要とする追加の仕様や実装作業はありません。
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.
クライアントは、GSS_INIT_SEC_CONTEXTを呼び出し、input_context_handle（初期）に0を渡し、gss_name_nameのinput_name_type from input_name_typeのinput_name_type from ftp@hostname "ftp@hostname" of "of" of "of" is the "of" of "one" of "as the" as the inupt_name_type from gss_name_type from gss_import_nameに渡すことにより、認証交換を開始する必要があります。すべての文字が小文字で、サーバーの完全な資格のあるホスト名。 （これに失敗すると、クライアントは「host@hostname」のinput_name_stringを使用して再試行することができます。）output_tokenは、base 64エンコードされ、adatコマンドへの引数としてサーバーに送信する必要があります。 gss_init_sec_contextがgss_s_s_continue_neededを返す場合、クライアントは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.
サーバーは、引数をADATコマンドにデコードし、結果のトークンをGSS_ACCEPT_SEC_CONTEXTに入力として渡し、accedor_cred_handleをnullに設定し（「デフォルトの資格情報を使用」）、入力_context_handleの0（最初）に渡す必要があります。output_tokenが返される場合、返信のテキストに「adat = base64string」を含めることにより、ベース64エンコードされ、クライアントに返される必要があります。gss_accept_sec_contextがgss_s_completeを返す場合、返信コードは235でなければならず、サーバーはクライアントが認証されていることを検討する必要があります。gss_accept_sec_contextがgss_s_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は匿名のピアをセキュリティコンテキストにサポートしているため、クライアントのサーバーの認証が実際にIDを確立しない可能性があります。
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 == 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_flag == with the sender for the senderの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が2回目に受信されたとき、または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.
クライアントは、krb_mk_req（3）を「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.
サーバーは、引数をADATコマンドにデコードし、結果をkrb_rd_req（3）に渡す必要があります。サーバーは、Authenticatorからチェックサムに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）に渡す必要があります。結果のチェックサムが以前に送信された値に等しい場合、クライアントはサーバーが認証されたサーバーを考慮する必要があります。
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_mk_safe（3）送信者のkrb_rd_safe（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_mk_priv（3）送信者用krb_rd_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.
Kerberos_V4のこの仕様には、整合性と機密性のルーチンのための代替手段を交渉するための規定が含まれていないことに注意してください。また、ADAT Exchangeは、ピアが機密保持サービスをサポートしているかどうかを伝えないことに注意してください。
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.
Copyright（c）The Internet Society（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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準のプロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。