Network Working Group T. Ts'o
Request for Comments: 2942 VA Linux Systems
Category: Standards Track September 2000
Telnet Authentication: Kerberos Version 5
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.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document describes how Kerberos Version 5 [1] is used with the telnet protocol. It describes an telnet authentication suboption to be used with the telnet authentication option [2]. This mechanism can also used to provide keying material to provide data confidentiality services in conjunction with the telnet encryption option [3].
この文書は、Kerberosバージョン5は、[1]のTelnetプロトコルで使用される方法を記載しています。それは、Telnet認証オプション[2]で使用するのTelnet認証サブオプションを記述する。このメカニズムはまたのtelnet暗号化オプション[3]と連動してデータの機密性サービスを提供するための鍵材料を提供するために使用することができます。
Authentication Types
認証タイプ
KERBEROS_V5 2
KERBEROS V5 2
Sub-option Commands
サブオプションのコマンド
AUTH 0 REJECT 1 ACCEPT 2 RESPONSE 3 FORWARD 4 FORWARD_ACCEPT 5 FORWARD_REJECT 6
FORWARD 2 RESPONSE 3 4 FORWARD_ACCEPT 5 FORWARD_REJECT 6 ACCEPT 1 REJECT AUTH 0
IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5 KRB_AP_REQ message> IAC SE
IAC SB認証は、<認証タイプ組> AUTH <ケルベロスV5 KRB_AP_REQメッセージ> IAC SE IS
This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the remote side of the connection. The first octet of the <authentication-type-pair> value is KERBEROS_V5, to indicate that Version 5 of Kerberos is being used. The Kerberos V5 authenticator in the KRB_AP_REQ message must contain a Kerberos V5 checksum of the two-byte authentication type pair. This checksum must be verified by the server to assure that the authentication type pair was correctly negotiated. The Kerberos V5 authenticator must also include the optional subkey field, which shall be filled in with a randomly chosen key. This key shall be used for encryption purposes if encryption is negotiated, and shall be used as the negotiated session key (i.e., used as keyid 0) for the purposes of the telnet encryption option; if the subkey is not filled in, then the ticket session key will be used instead.
これは接続の遠隔側にケルベロスV5 [1] KRB_AP_REQメッセージを渡すために使用されます。ケルベロスのバージョン5が使用されていることを示す<認証タイプ組>の最初のオクテット値がKERBEROS_V5あります。 KRB_AP_REQメッセージでケルベロスV5認証は、2バイトの認証タイプのペアのケルベロスV5チェックサムを含んでいなければなりません。このチェックサムは、認証タイプのペアが正しくネゴシエートされたことを保証するために、サーバーによって検証されなければなりません。ケルベロスV5認証はまた、ランダムに選択されたキーで埋めなければならない任意のサブキーフィールドを含まなければなりません。暗号化がネゴシエートされ、かつネゴシエートセッション鍵として使用されなければならない場合、このキーは、telnet暗号化オプションの目的のために（すなわち、鍵ID 0として使用される）暗号化のために使用しなければなりません。サブキーが記入されていない場合は、チケットのセッションキーが代わりに使用されます。
If data confidentiality services is desired the ENCRYPT_US-ING_TELOPT flag must be set in the authentication-type-pair as specified in [2].
データの機密性サービスが望まれる場合に指定されENCRYPT_US-ING_TELOPTフラグ[2]認証型ペアに設定されなければなりません。
IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE
IAC SB認証REPLY <認証タイプ組> ACCEPT IAC SE
This command indicates that the authentication was successful.
このコマンドは、認証が成功したことを示しています。
If the AUTH_HOW_MUTUAL bit is set in the second octet of the authentication-type-pair, the RESPONSE command must be sent before the ACCEPT command is sent.
AUTH_HOW_MUTUALビットが認証タイプ対の第2オクテットに設定されている場合、ACCEPTコマンドが送信される前に、応答コマンドが送信されなければなりません。
IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <optional reason for rejection> IAC SE
IAC SB認証REPLY <認証タイプ組>拒否<拒否のオプションの理由> 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テキストメッセージです。
IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE <KRB_AP_REP message> IAC SE
IAC SB認証REPLY <認証タイプ組>応答<KRB_AP_REPメッセージ> IAC SE
This command is used to perform mutual authentication. It is only used when the AUTH_HOW_MUTUAL bit is set in the second octet of the authentication-type-pair. After an AUTH command is verified, a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP message to perform the mutual authentication.
このコマンドは、相互認証を実行するために使用されます。 AUTH_HOW_MUTUALビットが認証タイプ対の第2オクテットに設定されているときにのみ使用されます。 AUTHコマンドが確認された後に、応答コマンドは、相互認証を実行するためのKerberos V5 KRB_AP_REPメッセージが含まれて送信されます。
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED message> IAC SE
IAC SB AUTHENTICATION <認証タイプ組> FORWARD <KRB_CREDメッセージ> IAC SE
This command is used to forward kerberos credentials for use by the remote session. The credentials are passed as a Kerberos V5 KRB_CRED message which includes, among other things, the forwarded Kerberos ticket and a session key associated with the ticket. Part of the KRB_CRED message is encrypted in the key previously exchanged for the telnet session by the AUTH suboption.
このコマンドは、リモートセッションでの使用のためのKerberos資格情報を転送するために使用されます。資格情報は、とりわけ、含まケルベロスV5 KRB_CREDメッセージ、転送されたKerberosチケットやチケットに関連したセッション鍵として渡されます。 KRB_CREDメッセージの一部は、以前AUTHサブオプションによって、telnetセッションのために交換した鍵で暗号化されています。
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC SE
IAC SB AUTHENTICATION <認証タイプ組> FORWARD_ACCEPT IAC SE
This command indicates that the credential forwarding was successful.
このコマンドは、資格の転送が成功したことを示しています。
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT <optional reason for rejection> IAC SE
IAC SB AUTHENTICATION <認証タイプ組> FORWARD_REJECT <拒否のオプションの理由> IAC SE
This command indicates that the credential forwarding was not successful, and if there is any more data in the suboption, it is an ASCII text message of the reason for the rejection.
このコマンドは、資格の転送が成功しなかったことを示し、およびサブオプションのいずれかのより多くのデータがある場合、それは拒否の理由のASCIIテキストメッセージです。
If the second octet of the authentication-type-pair has the AUTH_WHO bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial AUTH command, and the server responds with either ACCEPT or REJECT. In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the server will send a RESPONSE before it sends the ACCEPT.
認証タイプのペアの第2オクテットがAUTH_WHOがAUTH_CLIENT_TO_SERVERにビットセットされている場合、クライアントは初期のAUTHコマンドを送信し、サーバはACCEPTまたはREJECTのどちらかで応答します。 AUTH_HOWビットがAUTH_HOW_MUTUALに設定されている場合、それはACCEPTを送信する前に加えて、サーバが応答を送信します。
If the second octet of the authentication-type-pair has the AUTH_WHO bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial AUTH command, and the client responds with either ACCEPT or REJECT. In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the client will send a RESPONSE before it sends the ACCEPT.
認証タイプのペアの第2オクテットがAUTH_WHOビットたAUTH_SERVER_TO_CLIENTに設定すると、サーバーは、最初のAUTHコマンドを送信し、クライアントはACCEPTまたはREJECTのどちらかで応答します。 AUTH_HOWビットがAUTH_HOW_MUTUALに設定されている場合、それはACCEPTを送信する前に加えて、クライアントが応答を送信します。
The Kerberos principal used by the server will generally be of the form "host/<hostname>@realm". That is, the first component of the Kerberos principal is "host"; the second component is the fully qualified lower-case hostname of the server; and the realm is the Kerberos realm to which the server belongs.
サーバーが使用するKerberosプリンシパルは、一般形「のホスト/ <ホスト名> @realm」のものであろう。すなわち、Kerberosプリンシパルの第一成分が、「ホスト」です。第二成分は、サーバーの完全修飾小文字のホスト名です。レルムは、サーバが属するKerberosレルムです。
Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP messages, the KRB_CRED structure, or the optional rejection text string must be doubled as specified in [4]. Otherwise the following byte might be mis-interpreted as a Telnet command.
[4]で指定されるようにKRB_AP_REQ又はKRB_AP_REPメッセージ、KRB_CRED構造、又は任意拒絶テキスト文字列で発生する任意のTelnet IAC文字は倍増しなければなりません。それ以外の場合は、次のバイトはTelnetコマンドとして誤って解釈される可能性があります。
User "joe" may wish to log in as user "pete" on machine "foo". If "pete" has set things up on "foo" to allow "joe" access to his account, then the client would send IAC SB AUTHENTICATION NAME "pete" IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE> IAC SE
ユーザー「joeが」マシン「foo」という上のユーザー「ピート」としてログインすることもできます。 「ピート」は、自分のアカウントに「ジョー」のアクセスを許可するように、「FOO」で物事を設定している場合、クライアントはIAC SB AUTHENTICATION NAME「ピート」を送ってIAC SE IAC SB認証はKERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE> IAC SE IS
The server would then authenticate the user as "joe" from the KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by Kerberos, and if "pete" has allowed "joe" to use his account, the server would then continue the authentication sequence by sending a RESPONSE (to do mutual authentication, if it was requested) followed by the ACCEPT.
次に、サーバーはKRB_AP_REQ_MESSAGEから「ジョー」としてユーザーを認証だろう、とKRB_AP_REQ_MESSAGEは、Kerberosが受け入れられた場合、および「ピート」は自分のアカウントを使用するには、「ジョー」を許可している場合、サーバーは、送信して認証シーケンスを継続しますACCEPT続い応答（それが要求された場合、相互認証を行うため）。
If forwarding has been requested, the client then sends IAC SB AUTHENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED structure with credentials to be forwarded> IAC SE. If the server succeeds in reading the forwarded credentials, the server sends FORWARD_ACCEPT else, a FORWARD_REJECT is sent back.
MUTUAL FORWARD <転送するための資格情報を持つKRB_CRED構造> IAC SE |転送が要求されている場合、クライアントは、IAC SB認証はKERBEROS_V5クライアントです送信します。サーバが転送された資格情報を読んで成功すると、サーバーはFORWARD_REJECTが返送され、それ以外のFORWARD_ACCEPTを送信します。
Client Server
IAC DO AUTHENTICATION
IAC WILL AUTHENTICATION
[ The server is now free to request authentication information. ]
[サーバーが認証情報を要求して自由です。 ]
IAC SB AUTHENTICATION SEND
KERBEROS_V5 CLIENT|MUTUAL
KERBEROS_V5 CLIENT|ONE_WAY IAC
SE
[ The server has requested mutual Version 5 Kerberos authentication. If mutual authentication is not supported, then the server is willing to do one-way authentication.
[サーバーは相互バージョン5のKerberos認証を要求しました。相互認証がサポートされていない場合、サーバーは、一方向認証を行うには喜んで。
The client will now respond with the name of the user that it wants to log in as, and the Kerberos ticket. ]
クライアントは、今ではとしてログインしたいユーザーの名前、およびKerberosチケットで応答します。 ]
IAC SB AUTHENTICATION NAME "pete" IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 CLIENT|MUTUAL AUTH <KRB_AP_REQ message> IAC SE
IAC SB認証NAME "ピート" IAC SE IAC SB認証はKERBEROS_V5クライアントです| MUTUAL AUTH <KRB_AP_REQメッセージ> IAC SE
[ Since mutual authentication is desired, the server sends across a RESPONSE to prove that it really is the right server. ]
相互認証が要求されるので、[、サーバーはそれが本当に正しいサーバであることを証明することに応答全体に送信します。 ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V5 CLIENT|MUTUAL
RESPONSE <KRB_AP_REP message>
IAC SE
[ The server responds with an ACCEPT command to state that the authentication was successful. ]
[サーバは認証が成功したことを述べることACCEPTコマンドに応答します。 ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V5 CLIENT|MUTUAL ACCEPT
IAC SE
[ If so requested, the client now sends the FORWARD command to forward credentials to the remote site. ]
その要求された場合は、[、クライアントはリモートサイトに資格情報を転送するFORWARDコマンドを送信します。 ]
IAC SB AUTHENTICATION IS KER-BEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED message> IAC SE
IAC SB認証はKER-BEROS_V5クライアントです|相互FORWARD <KRB_CREDメッセージ> IAC SE
[ The server responds with a FORWARD_ACCEPT command to state that the credential forwarding was successful. ]
[サーバーは、資格の転送が成功したことを述べるためにFORWARD_ACCEPTコマンドで応答します。 ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V5 CLIENT|MUTUAL
FORWARD_ACCEPT IAC SE
The selection of the random session key in the Kerberos V5 authenticator is critical, since this key will be used for encrypting the telnet data stream if encryption is enabled. It is strongly advised that the random key selection be done using cryptographic techniques that involve the Kerberos ticket's session key. For example, using the current time, encrypting it with the ticket session key, and then correcting for key parity is a strong way to generate a subsession key, since the ticket session key is assumed to be never disclosed to an attacker.
このキーは暗号化が有効になっている場合のtelnetデータストリームを暗号化するために使用されますので、ケルベロスV5認証におけるランダムセッションキーの選択は、非常に重要です。強くランダムキーの選択は、Kerberosチケットのセッション・キーを必要とする暗号技術を使用して行われることをお勧めします。例えば、チケットのセッション鍵で暗号化し、現在の時刻を使用して、キーのパリティを補正すると、チケットのセッション鍵が攻撃者に開示することはありませんことを想定しているため、サブセッションキーを生成するための強力な方法です。
Care should be taken before forwarding a user's Kerberos credentials to the remote server. If the remote server is not trustworthy, this could result in the user's credentials being compromised. Hence, the user interface should not forward credentials by default; it would be far safer to either require the user to explicitly request credentials forwarding for each connection, or to have a trusted list of hosts for which credentials forwarding is enabled, but to not enable credentials forwarding by default for all machines.
ケアは、リモートサーバーへのユーザーのKerberos資格情報を転送する前に取られるべきです。リモートサーバーが信頼されていない場合、これはユーザーの資格情報が危険にさらされているにつながる可能性があります。したがって、ユーザインターフェイスは、デフォルトで資格情報を転送するべきではありません。どちらかが、ユーザが必要とするためには、明示的に接続ごとに転送する資格情報を要求するために、または資格情報が有効になっている転送対象のホストの信頼されたリストを持っているが、すべてのマシンにデフォルトで転送する資格情報を有効にしないためにはるかに安全になります。
The IAC SB AUTHENTICATION NAME name IAC SE message is unprotected in this protocol. Its contents should be verified by a secure method after authentication completes before it is used.
IAC SB認証名名IAC SEメッセージは、このプロトコルで保護されていないです。それが使用される前に認証が完了した後、その内容は、安全な方法で確認する必要があります。
The authentication type KERBEROS_V5 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.
認証タイプKERBEROS_V5およびその関連サブオプションの値は、IANAに登録されています。この文書に記載されているようにプロトコルを拡張するために使用される任意のサブオプションの値は、使用前にIANAに登録されなければなりません。 IANAは、それらの使用の文書の提出せずに新しいサブオプション値を発行しないように指示されます。
This document was originally written by Dave Borman of Cray Research, Inc. Theodore Ts'o of MIT revised it to reflect the latest implementation experience. Cliff Neuman and Prasad Upasani of USC's Information Sciences Institute developed the credential forwarding support.
この文書は、もともとクレイリサーチのデイブ・ボーマンによって書かれた、MITの株式会社セオドア・ツォーは、最新の実装経験を反映して、それを修正しました。クリフノイマンとUSCの情報科学研究所のプラサドUpasaniは、資格情報の転送をサポートして開発しました。
In addition, the contributions of the Telnet Working Group are also gratefully acknowledged.
また、Telnetの作業部会の貢献も深く感謝しています。
[1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication System (V5)", RFC 1510, September 1993.
[1]コールズ、J.及びB.ノイマン、 "ケルベロスネットワーク認証システム（V5）"、RFC 1510、1993年9月。
[2] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941, September 2000.
[2] Ts'oさん、T.及びJ.アルトマン、 "Telnetの認証オプション"、RFC 2941、2000年9月。
[3] Ts'o, T., "Telnet Data Encryption Option", RFC 2946, September 2000.
[3] Ts'oさん、T.、 "Telnetのデータ暗号化オプション"、RFC 2946、2000年9月。
[4] Postel, J. and J. Reynolds, "Telnet Option Specifications", STD 8, RFC 855, May 1983.
[4]ポステル、J.、およびJ.レイノルズ、 "Telnetオプション仕様"、STD 8、RFC 855、1983月。
Theodore Ts'o VA Linux Systems 43 Pleasant St. Medford, MA 02155
セオドア・ツォーVA Linuxシステム43プレザントセントメドフォード、MA 02155
Phone: (781) 391-3464 EMail: tytso@mit.edu
電話：（781）391-3464 Eメール：tytso@mit.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。