[要約] RFC 2944は、Telnet認証におけるSRP（Secure Remote Password）プロトコルについての仕様です。SRPは、セキュアなパスワード認証を提供するために設計されており、セキュリティを向上させることを目的としています。
Network Working Group T. Wu
Request for Comments: 2944 Standford University
Category: Standards Track September 2000
Telnet Authentication: SRP
Telnet認証：SRP
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 (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document specifies an authentication scheme for the Telnet protocol under the framework described in [RFC2941], using the Secure Remote Password Protocol (SRP) authentication mechanism. The specific mechanism, SRP-SHA1, is described in [RFC2945].
このドキュメントは、[RFC2941]で説明されているフレームワークに基づくTelnetプロトコルの認証スキームを指定し、安全なリモートパスワードプロトコル（SRP）認証メカニズムを使用します。特定のメカニズムであるSRP-SHA1は、[RFC2945]に記載されています。
Authentication Types
認証タイプ
SRP 5
SRP 5
Suboption Commands
サブオプションコマンド
AUTH 0 REJECT 1 ACCEPT 2 CHALLENGE 3 RESPONSE 4
Auth0拒否1 Accept 2 Challenge 3 Response 4
EXP 8 PARAMS 9
Exp 8 Params 9
IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH IAC SE
IAC SB認証は<authentication-type-pair> auth iac seです
This command indicates that the client has supplied the username and is ready to receive that user's field parameters. There is no authentication information to be sent to the remote side of the connection yet. This should only be sent after the IAC SB AUTHENTICATION NAME command has been issued. If the modifier byte (second byte of the authentication-type-pair) has any bits other than AUTH_WHO_MASK or AUTH_HOW_MASK set, both bytes are included in the session key hash described later. This ensures that the authentication type pair was correctly negotiated, while maintaining backward-compatibility with existing software.
このコマンドは、クライアントがユーザー名を提供し、そのユーザーのフィールドパラメーターを受信する準備ができていることを示しています。接続のリモート側に送信する認証情報はまだありません。これは、IAC SB認証名コマンドが発行された後にのみ送信する必要があります。モディファイアバイト（認証タイプペアの2番目のバイト）にauth_who_maskまたはauth_how_maskセット以外のビットがある場合、両方のバイトが後述のセッションキーハッシュに含まれています。これにより、既存のソフトウェアとの後方互換性を維持しながら、認証タイプのペアが正しく交渉されました。
IAC SB AUTHENTICATION REPLY <authentication-type-pair> PARAMS <values
of modulus, generator, and salt> IAC SE
This command is used to pass the three parameter values used in the exponentiation to the client. These values are often called n, g, and s.
このコマンドは、クライアントへの指数化で使用される3つのパラメーター値を渡すために使用されます。これらの値は、しばしばn、g、およびsと呼ばれます。
IAC SB AUTHENTICATION IS <authentication-type-pair> EXP <client's
exponential residue> IAC SE
This command is used to pass the client's exponential residue, otherwise known as A, computed against the parameters exchanged earlier.
このコマンドは、以前に交換されたパラメーターに対して計算されたAとして知られるクライアントの指数残基を渡すために使用されます。
IAC SB AUTHENTICATION REPLY <authentication-type-pair> CHALLENGE
<server's exponential residue> IAC SE
This command is used to pass the server's exponential residue, computed against the same parameters. This quantity is actually the sum of two residues, i.e. g^x + g^b. For details see [SRP] and [RFC2945].
このコマンドは、同じパラメーターに対して計算されたサーバーの指数残基を渡すために使用されます。この量は、実際には2つの残基、つまりg^x g^bの合計です。詳細については、[SRP]および[RFC2945]を参照してください。
IAC SB AUTHENTICATION IS <authentication-type-pair> RESPONSE
<response from client> IAC SE
This command gives the server proof of the client's authenticity with a 160-bit (20 byte) response.
このコマンドは、160ビット（20バイト）の応答でクライアントの信頼性のサーバーの証明を提供します。
IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT
<server's response> IAC SE
This command indicates that the authentication was successful. The server will construct its own proof of authenticity and include it as sub-option data.
このコマンドは、認証が成功したことを示しています。サーバーは、独自の信頼性の証明を構築し、サブオプションデータとして含めます。
IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT
<optional reason for rejection> IAC SE
This command indicates that the authentication was not successful, and if there is any more data in the sub-option, it is an ASCII text message of the reason for the rejection.
このコマンドは、認証が成功しなかったことを示しており、サブオプションにこれ以上のデータがある場合、拒否の理由のASCIIテキストメッセージです。
For the PARAMS command, since three pieces of data are being transmitted, each parameter is preceded by a 16-bit (two byte) length specifier in network byte order. The EXP commands do not have a count in front of the data because there is only one piece of data in that suboption. The CHALLENGE, RESPONSE, and ACCEPT data also do not have a count because they are all fixed in size.
PARAMSコマンドの場合、3つのデータが送信されているため、各パラメーターの前にネットワークバイトの順序で16ビット（2バイト）の長さ指定子があります。EXPコマンドは、そのサブオプションにデータが1つしかないため、データの前にカウントがありません。課題、応答、および受け入れデータも、すべてサイズが固定されているため、カウントはありません。
Currently, only AUTH_CLIENT_TO_SERVER mode is supported. Although the SRP protocol effectively performs implicit mutual authentication as a result of the two-way proofs, only the AUTH_HOW_ONE_WAY authentication mode is currently defined. The AUTH_HOW_MUTUAL setting is being reserved for an explicit mutual-authentication variant of the SRP protocol to be defined in future specifications.
現在、auth_client_to_serverモードのみがサポートされています。SRPプロトコルは、双方向の証明の結果として暗黙的な相互認証を効果的に実行しますが、Auth_how_one_way認証モードのみが現在定義されています。auth_how_mutual設定は、将来の仕様で定義されるSRPプロトコルの明示的な相互承認バリアントが予約されています。
All large number data sent in the arguments of the PARAMS and EXP commands must be in network byte order, i.e. most significant byte first. No padding is used.
PARAMSおよびEXPコマンドの引数で送信されたすべての多数のデータは、ネットワークバイトの順序でなければなりません。つまり、最初に最も重要なバイトです。パディングは使用されていません。
The SRP-SHA1 mechanism, as described in [RFC2945] generates a 40-byte session key, which allows implementations to use different keys for incoming and outgoing traffic, increasing the security of the encrypted session. It is recommended that the Telnet ENCRYPT method, if it is used, be able to take advantage of the longer session keys.
[RFC2945]で説明されているように、SRP-Sha1メカニズムは40バイトセッションキーを生成します。これにより、実装が着信および発信トラフィックに異なるキーを使用して、暗号化されたセッションのセキュリティが増加します。Telnet暗号化法を使用すると、より長いセッションキーを利用できるようにすることをお勧めします。
User "tjw" may wish to log in on machine "foo". The client would send IAC SB AUTHENTICATION NAME "tjw" IAC SE IAC SB AUTHENTICATION IS SRP AUTH IAC SE. The server would look up the field and salt parameters for "tjw" from its password file and send them back to the client. Client and server would then exchange exponential residues and calculate their session keys (after the client prompted "tjw" for his password). Then, the client would send the server its proof that it knows the session key. The server would either send back an ACCEPT or a REJECT. If the server accepts authentication, it also sends its own proof that it knows the session key to the client.
ユーザー「TJW」は、マシン「foo」にログインすることをお勧めします。クライアントは、IAC SB認証名「TJW」IAC SE IAC SB認証を送信します。サーバーは、パスワードファイルから「TJW」のフィールドと塩パラメーターを検索し、クライアントに送り返します。クライアントとサーバーは、指数残基を交換してセッションキーを計算します（クライアントがパスワードについて「TJW」をプロンプトした後）。次に、クライアントはサーバーにセッションキーがわかっていることの証拠を送信します。サーバーは、受け入れまたは拒否を送り返します。サーバーが認証を受け入れると、セッションキーがクライアントに鍵を把握しているという独自の証拠も送信します。
Client Server IAC DO AUTHENTICATION IAC WILL AUTHENTICATION
クライアントサーバーIACは認証を行いますIACは認証を行います
[ The server is now free to request authentication information. ] IAC SB AUTHENTICATION SEND SRP CLIENT|ONE_WAY| ENCRYPT_USING_TELOPT SRP CLIENT|ONE_WAY IAC SE
[サーバーは、認証情報を自由にリクエストできるようになりました。] IAC SB認証はSRPクライアントを送信| One_way |encrypt_using_telopt srp client | one_way iac se
[ The server has requested SRP authentication. It has indicated a preference for ENCRYPT_USING_TELOPT, which requires the Telnet ENCRYPT option to be negotiated once authentication succeeds. If the client does not support this, the server is willing to fall back to an encryption-optional mode.
[サーバーはSRP認証を要求しています。encrypt_using_teloptの好みを示しています。これには、認証が成功すると、Telnet暗号化オプションを交渉する必要があります。クライアントがこれをサポートしていない場合、サーバーは暗号化オプションモードに戻ることをいとわない。
The client will now respond with the name of the user that it wants to log in as. ]
クライアントは、ログインしたいユーザーの名前で応答します。]
IAC SB AUTHENTICATION NAME "tjw" IAC SE IAC SB AUTHENTICATION IS SRP CLIENT|ONE_WAY|ENCRYPT_USING_TELOPT AUTH IAC SE
IAC SB認証名「TJW」
[ The server looks up the appropriate information for "tjw" and sends back the parameters in a PARAMS command. The parameters consist of the values N, g, and s, each preceded with a two-byte size parameter. ]
[サーバーは、「TJW」の適切な情報を検索し、Paramsコマンドのパラメーターを返送します。パラメーターは、値n、g、およびsで構成され、それぞれに2バイトのサイズパラメーターがあります。]
IAC SB AUTHENTICATION REPLY SRP CLIENT|ONE_WAY| ENCRYPT_USING_TELOPT PARAMS ss ss nn nn nn nn ... ss ss gg gg gg gg ... ss ss tt tt tt tt ... IAC SE
IAC SB認証応答SRPクライアント| One_way |encrypt_using_telopt params ss ss nn nn nn nn ... ss ss gg gg gg gg ... ss ss tt tt tt tt ... iac se
[ Both sides send their exponential residues. The client sends its value A and the server sends its value B. In SRP, the CHALLENGE message may be computed but not sent before the EXP command. ]
[両側は指数残基を送ります。クライアントはその値Aを送信し、サーバーはその値Bを送信します。SRPでは、課題メッセージは計算されますが、EXPコマンドの前に送信されません。]
IAC SB AUTHENTICATION IS SRP CLIENT|ONE_WAY|ENCRYPT_USING_TELOPT EXP aa aa aa aa aa aa aa aa ... IAC SE IAC SB AUTHENTICATION REPLY SRP CLIENT|ONE_WAY| ENCRYPT_USING_TELOPT CHALLENGE bb bb bb bb bb bb bb bb ... IAC SE
IAC SB認証はSRPクライアントです| One_way | necrypt_using_telopt exp aa aa aa aa aa aa aa ... iac sb認証返信| one_way |Encrypt_using_telopt Challenge bb bb bb bb bb bb bb bb ... iac se
[ The client sends its response to the server. This is the message M in the SRP protocol, which proves possession of the session key by the client.
[クライアントはサーバーに応答を送信します。これは、SRPプロトコルのメッセージMであり、クライアントによるセッションキーの所有を証明しています。
Since ENCRYPT_USING_TELOPT is specified, the two octets of the authentication-type-pair are appended to the session key K before the hash for M is computed. If the client and server had agreed upon a mode without the encryption flag set, nothing would be appended to K.
encrypt_using_teloptが指定されているため、Mのハッシュが計算される前に、認証タイプペアの2オクテットがセッションキーKに追加されます。クライアントとサーバーが暗号化フラグが設定されていないモードに同意した場合、kに追加されるものはありません。
Both this message and the server's response are as long as the output of the hash; the length is 20 bytes for SHA-1. ]
このメッセージとサーバーの応答の両方は、ハッシュの出力と同じ長さです。SHA-1の長さは20バイトです。]
IAC SB AUTHENTICATION IS SRP CLIENT|ONE_WAY|ENCRYPT_USING_TELOPT RESPONSE xx xx xx xx xx xx xx xx ... IAC SE
IAC SB認証はSRPクライアントです| One_way | encrypt_using_telopt Response xx xx xx xx xx xx xx xx ... iac se
[ The server accepts the response and sends its own proof. ]
[サーバーは応答を受け入れ、独自の証明を送信します。]
IAC SB AUTHENTICATION REPLY SRP CLIENT|ONE_WAY| ENCRYPT_USING_TELOPT ACCEPT yy yy yy yy yy yy yy yy ... IAC SE
IAC SB認証応答SRPクライアント| One_way |encrypt_using_teloptはyyyy yy yy yy yy yy yy ... iac seを受け入れる
The ability to negotiate a common authentication mechanism between client and server is a feature of the authentication option that should be used with caution. When the negotiation is performed, no authentication has yet occurred. Therefore, each system has no way of knowing whether or not it is talking to the system it intends. An intruder could attempt to negotiate the use of an authentication system which is either weak, or already compromised by the intruder.
クライアントとサーバーの間の一般的な認証メカニズムをネゴシエートする機能は、慎重に使用する必要がある認証オプションの機能です。交渉が実行されると、認証はまだ発生していません。したがって、各システムには、意図したシステムに話しかけているかどうかを知る方法がありません。侵入者は、侵入者によって弱い、またはすでに妥協されている認証システムの使用を交渉しようとすることができます。
Since SRP relies on the security of the underlying public-key cryptosystem, the modulus "n" should be large enough to resist brute-force attack. A length of at least 1024 bits is recommended, and implementations should reject attempts to use moduli that are shorter than 512 bits, or attempts to use invalid moduli and generator parameters (non-safe-prime "n" or non-primitive "g").
SRPは、基礎となるパブリックキー暗号システムのセキュリティに依存しているため、モジュラス "n"はブルートフォース攻撃に抵抗するのに十分な大きさでなければなりません。少なくとも1024ビットの長さが推奨されます。実装は、512ビットよりも短いモジュリを使用しようとする試みを拒否するか、無効なモジュリとジェネレーターのパラメーター（非セーフプライム "N"または非微量性「G」を使用する試みを拒否する必要があります。）。
The authentication type SRP and its associated suboption values are registered with IANA. Any suboption values used to extend the protocol as described in this document must be registered with IANA before use. IANA is instructed not to issue new suboption values without submission of documentation of their use.
認証タイプのSRPとそれに関連するサブオプション値は、IANAに登録されています。このドキュメントで説明されているプロトコルを拡張するために使用されるサブオプション値は、使用前にIANAに登録する必要があります。IANAは、使用の文書を提出せずに新しいサブオプション値を発行しないように指示されています。
[RFC2941] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941, September 2000.
[RFC2941] Ts'o、T。およびJ. Altman、「Telnet認証オプション」、RFC 2941、2000年9月。
[SRP] T. Wu, "The Secure Remote Password Protocol", In Proceedings of the 1998 ISOC Network and Distributed System Security Symposium, San Diego, CA, pp. 97-111.
[SRP] T. Wu、「セキュアーリモートパスワードプロトコル」、1998年のISOCネットワークおよび分散システムセキュリティシンポジウムの議事録、カリフォルニア州サンディエゴ、97-111ページ。
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.
[RFC2945] Wu、T。、「SRP認証およびキー交換システム」、RFC 2945、2000年9月。
Thomas Wu Stanford University Stanford, CA 94305
トーマスウースタンフォード大学スタンフォード、カリフォルニア州94305
EMail: tjw@cs.Stanford.EDU
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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 implementation may be prepared, copied, published and 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。