[要約] RFC 2942は、Telnet認証におけるKerberosバージョン5のプロトコルを定義しています。目的は、セキュアなTelnetセッションの確立と、ユーザーの認証情報の保護です。
Network Working Group T. Ts'o
Request for Comments: 2942 VA Linux Systems
Category: Standards Track September 2000
Telnet Authentication: Kerberos Version 5
Telnet認証：Kerberosバージョン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.
Copyright（c）The Internet Society（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
IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5
KRB_AP_REQ message> IAC SE
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.
これは、kerberos v5 [1] krb_ap_reqメッセージを接続のリモート側に渡すために使用されます。<Authentication-Type-Pair>値の最初のオクテットはKerberos_V5です。Kerberosのバージョン5が使用されていることを示しています。KRB_AP_REQメッセージのKerberos V5 Authenticatorには、2バイト認証タイプペアのKerberos V5チェックサムが含まれている必要があります。このチェックサムは、認証タイプのペアが正しく交渉されたことを保証するために、サーバーによって検証する必要があります。Kerberos V5認証器には、ランダムに選択されたキーが記入されるオプションのサブキーフィールドも含める必要があります。このキーは、暗号化がネゴシエートされた場合、暗号化の目的で使用され、Telnet暗号化オプションの目的のためにネゴシエートされたセッションキー（つまり、KeyID 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].
データの機密保持サービスが必要な場合、[2]で指定されているように、encrypt_us-ing_teloptフラグを認証型ペアで設定する必要があります。
IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE
IAC SB認証REPLY <Authentication-Type-Pair> 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 Bitが認証型ペアの2番目のオクテットに設定されている場合、compateコマンドが送信される前に応答コマンドを送信する必要があります。
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テキストメッセージです。
IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE
<KRB_AP_REP message> 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 Bitが認証タイプペアの2番目のオクテットで設定されている場合にのみ使用されます。認証コマンドが検証された後、相互認証を実行するためにKerberos V5 KRB_AP_REPメッセージを含む応答コマンドが送信されます。
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED
message> 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資格情報を転送するために使用されます。資格情報は、とりわけ、転送されたKerberosチケットとチケットに関連付けられたセッションキーを含むKerberos V5 KRB_CREDメッセージとして渡されます。KRB_CREDメッセージの一部は、Auth SuboptionによってTelnetセッションと以前に交換されたキーで暗号化されています。
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC SE
IAC SB Authentication <Authentication-Type-Pair> 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
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.
Authentication-Type-Pairの2番目のOctetがauth_who bitをauth_client_to_serverに設定している場合、クライアントは初期authコマンドを送信し、サーバーは受け入れるか拒否します。さらに、auth_howビットがauth_how_mutualに設定されている場合、サーバーは受け入れを送信する前に応答を送信します。
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.
Authentication-Type-Pairの2番目のオクテットがauth_who bitをauth_server_to_clientに設定している場合、サーバーは初期authコマンドを送信し、クライアントは受け入れるか拒否します。さらに、auth_howビットがauth_how_mutualに設定されている場合、クライアントは受け入れを送信する前に応答を送信します。
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の校長は、一般に「host/<hostname> @realm」という形式です。つまり、Kerberosの校長の最初のコンポーネントは「ホスト」です。2番目のコンポーネントは、サーバーの完全に適格な低ケースホスト名です。そして、領域はサーバーが属する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.
KRB_AP_REQまたはKRB_AP_REPメッセージで発生するTelnet IAC文字、KRB_CRED構造、またはオプションの拒否テキスト文字列は[4]で指定されているように2倍にする必要があります。それ以外の場合、次のバイトが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」は、Machine "foo"でユーザー「Pete」としてログインしたい場合があります。「ピート」が「foo」に「joe」アクセスを許可するように「foo」を設定している場合、クライアントはIAC SB認証名「ピート」を送信します。
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から「Joe」として認証し、KRB_AP_REQ_MESSAGEがKerberosに受け入れられた場合、「Pete」が「Joe」がアカウントを使用することを許可した場合、サーバーはAを送信して認証シーケンスを続行し続けます。応答（要求された場合は相互認証を行うため）に続いて受け入れます。
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.
転送が要求されている場合、クライアントはIAC SB認証を送信します。サーバーが転送された資格情報の読み取りに成功した場合、サーバーはforward_acceptを送信します。
Client Server IAC DO AUTHENTICATION IAC WILL AUTHENTICATION
クライアントサーバーIACは認証を行いますIACは認証を行います
[ The server is now free to request authentication information. ]
[サーバーは、認証情報を自由にリクエストできるようになりました。]
IAC SB AUTHENTICATION SEND KERBEROS_V5 CLIENT|MUTUAL KERBEROS_V5 CLIENT|ONE_WAY IAC SE
IAC SB認証kerberos_v5クライアントを送信|相互kerberos_v5クライアント| 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認証名「Pete」
[ 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
IAC SB認証返信kerberos_v5クライアント|相互応答<krb_ap_repメッセージ> iac se
[ The server responds with an ACCEPT command to state that the authentication was successful. ]
[サーバーは、認証が成功したと述べるために、受け入れコマンドで応答します。]
IAC SB AUTHENTICATION REPLY KERBEROS_V5 CLIENT|MUTUAL ACCEPT IAC SE
IAC SB認証返信Kerberos_V5クライアント|相互承認IAC SE
[ If so requested, the client now sends the FORWARD command to forward credentials to the remote site. ]
[そのように要求された場合、クライアントはフォワードコマンドをリモートサイトに転送するために送信します。]
IAC SB AUTHENTICATION IS KER-BEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED message> IAC SE
IAC SB認証はker-beros_v5クライアント|相互フォワード<krb_cred message> 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
IAC SB認証返信kerberos_v5クライアント|相互forward_accept iac se 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.
Kerberos V5認証器のランダムセッションキーの選択は重要です。このキーは、暗号化が有効になっている場合にTelnetデータストリームの暗号化に使用されるためです。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のTheodore TS'oのDave Bormanが、最新の実装体験を反映するように改訂したDave Bormanによって書かれました。USCのInformation Sciences InstituteのCliff NeumanとPrasad 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] Kohl、J。and B. Neuman、「The Kerberos Network Authentication System（V5）」、RFC 1510、1993年9月。
[2] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941, September 2000.
[2] Ts'o、T。およびJ. Altman、「Telnet認証オプション」、RFC 2941、2000年9月。
[3] Ts'o, T., "Telnet Data Encryption Option", RFC 2946, September 2000.
[3] Ts'o、T。、「Telnet Data暗号化オプション」、RFC 2946、2000年9月。
[4] Postel, J. and J. Reynolds, "Telnet Option Specifications", STD 8, RFC 855, May 1983.
[4] Postel、J。およびJ. Reynolds、「Telnetオプション仕様」、STD 8、RFC 855、1983年5月。
Theodore Ts'o VA Linux Systems 43 Pleasant St. Medford, MA 02155
セオドアTS'O VA Linux Systems 43 Pleasant St. Medford、MA 02155
Phone: (781) 391-3464 EMail: tytso@mit.edu
電話：（781）391-3464メール：tytso@mit.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エディター機能の資金は現在、インターネット協会によって提供されています。