Network Working Group J. Hutzelman
Request for Comments: 4462 CMU
Category: Standards Track J. Salowey
Cisco Systems
J. Galbraith
Van Dyke Technologies, Inc.
V. Welch
U Chicago / ANL
May 2006
Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
セキュアシェル（SSH）プロトコルのための一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）の認証と鍵交換
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network.
Secure Shellプロトコル（SSH）は、安全でないネットワーク上の安全なリモートログイン及び他の安全なネットワークサービスのためのプロトコルです。
The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion.
一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）は、メカニズムに依存しない形式で発信者に対してセキュリティサービスを提供します。
This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method that uses a specified GSS-API mechanism to authenticate a user, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange.
このメモは、認証およびSSHでの鍵交換用のGSS-APIを使用する方法を説明しています。これは、ユーザーを認証するために指定されたGSS-APIメカニズムを使用してSSHのユーザ認証方式、およびDiffie-Hellman鍵交換を認証するためにGSS-APIを使用してSSH鍵交換メソッドのファミリを定義します。
This memo also defines a new host public key algorithm that can be used when no operations are needed using a host's public key, and a new user authentication method that allows an authorization name to be used in conjunction with any authentication that has already occurred as a side-effect of GSS-API-based key exchange.
また、このメモは許可名が既にとして発生している任意の認証と組み合わせて使用することができます何も操作がホストの公開鍵を使用して、必要に応じていないときに使用できる新しいホスト公開鍵アルゴリズム、および新規ユーザの認証方法を定義しますGSS-APIベースの鍵交換の副作用。
Table of Contents
目次
1. Introduction ....................................................3
1.1. SSH Terminology ............................................3
1.2. Key Words ..................................................3
2. GSS-API-Authenticated Diffie-Hellman Key Exchange ...............3
2.1. Generic GSS-API Key Exchange ...............................4
2.2. Group Exchange ............................................10
2.3. gss-group1-sha1-* .........................................11
2.4. gss-group14-sha1-* ........................................12
2.5. gss-gex-sha1-* ............................................12
2.6. Other GSS-API Key Exchange Methods ........................12
3. GSS-API User Authentication ....................................13
3.1. GSS-API Authentication Overview ...........................13
3.2. Initiating GSS-API Authentication .........................13
3.3. Initial Server Response ...................................14
3.4. GSS-API Session ...........................................15
3.5. Binding Encryption Keys ...................................16
3.6. Client Acknowledgement ....................................16
3.7. Completion ................................................17
3.8. Error Status ..............................................17
3.9. Error Token ...............................................18
4. Authentication Using GSS-API Key Exchange ......................19
5. Null Host Key Algorithm ........................................20
6. Summary of Message Numbers .....................................21
7. GSS-API Considerations .........................................22
7.1. Naming Conventions ........................................22
7.2. Channel Bindings ..........................................22
7.3. SPNEGO ....................................................23
8. IANA Considerations ............................................24
9. Security Considerations ........................................24
10. Acknowledgements ..............................................25
11. References ....................................................26
11.1. Normative References .....................................26
11.2. Informative References ...................................27
This document describes the methods used to perform key exchange and user authentication in the Secure Shell protocol using the GSS-API. To do this, it defines a family of key exchange methods, two user authentication methods, and a new host key algorithm. These definitions allow any GSS-API mechanism to be used with the Secure Shell protocol.
このドキュメントでは、GSS-APIを使用してSecure Shellプロトコルにおける鍵交換とユーザ認証を実行するために使用する方法について説明します。これを行うには、それが鍵交換方式、2つのユーザー認証方法、および新しいホスト鍵アルゴリズムのファミリーを定義します。これらの定義は、任意のGSS-APIメカニズムは、Secure Shellプロトコルを使用することができます。
This document should be read only after reading the documents describing the SSH protocol architecture [SSH-ARCH], transport layer protocol [SSH-TRANSPORT], and user authentication protocol [SSH-USERAUTH]. This document freely uses terminology and notation from the architecture document without reference or further explanation.
この文書は、トランスポート層プロトコル[SSH-TRANSPORT]、およびユーザ認証プロトコル[SSH-USERAUTH]、SSHプロトコルアーキテクチャ[SSH-ARCH]を記述した文書を読んだ後に読まれるべきです。この文書は、自由に参照またはさらなる説明なしアーキテクチャ文書からの用語および表記法を使用します。
The data types used in the packets are defined in the SSH architecture document [SSH-ARCH]. It is particularly important to note the definition of string allows binary content.
パケットで使用されるデータ型はSSHアーキテクチャドキュメント[SSH-ARCH]で定義されています。文字列の定義は、バイナリコンテンツを可能に注意することが特に重要です。
The SSH_MSG_USERAUTH_REQUEST packet refers to a service; this service name is an SSH service name and has no relationship to GSS-API service names. Currently, the only defined service name is "ssh-connection", which refers to the SSH connection protocol [SSH-CONNECT].
SSH_MSG_USERAUTH_REQUESTパケットがサービスを指します。このサービス名は、SSHサービス名で、GSS-APIサービス名とは関係ありません。現在、唯一の定義されたサービス名は、SSH接続プロトコル[SSH-CONNECT]を指し、「SSH接続」、です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
This section defines a class of key exchange methods that combine the Diffie-Hellman key exchange from Section 8 of [SSH-TRANSPORT] with mutual authentication using GSS-API.
このセクションでは、GSS-APIを使用して相互認証を有する[SSH-TRANSPORT]のセクション8からのDiffie-Hellman鍵交換を組み合わせた鍵交換メソッドのクラスを定義します。
Since the GSS-API key exchange methods described in this section do not require the use of public key signature or encryption algorithms, they MAY be used with any host key algorithm, including the "null" algorithm described in Section 5.
このセクションで説明するGSS-API鍵交換方法は、公開鍵署名や暗号化アルゴリズムの使用を必要としないので、彼らは第5節で説明した「ヌル」アルゴリズムを含む、任意のホスト鍵アルゴリズムで使用されるかもしれません。
The following symbols are used in this description:
以下のシンボルが、この説明で使用されています。
o C is the client, and S is the server
O Cはクライアントであり、Sは、サーバであります
o p is a large safe prime, g is a generator for a subgroup of GF(p), and q is the order of the subgroup
O pが大きい安全素数であり、GはGF（P）のサブグループのジェネレータであり、qはサブグループの順序であります
o V_S is S's version string, and V_C is C's version string
O V_SはSのバージョン文字列で、V_CはCのバージョン文字列であります
o I_C is C's KEXINIT message, and I_S is S's KEXINIT message
O I_CはCのKEXINITメッセージであり、そしてI_SはSのKEXINITメッセージです
1. C generates a random number x (1 < x < q) and computes e = g^x mod p.
1. Cは、ランダム番号x（1 <x <q）を生成し、E = G ^ Xのmod Pを計算します。
2. C calls GSS_Init_sec_context(), using the most recent reply token received from S during this exchange, if any. For this call, the client MUST set mutual_req_flag to "true" to request that mutual authentication be performed. It also MUST set integ_req_flag to "true" to request that per-message integrity protection be supported for this context. In addition, deleg_req_flag MAY be set to "true" to request access delegation, if requested by the user. Since the key exchange process authenticates only the host, the setting of anon_req_flag is immaterial to this process. If the client does not support the "gssapi-keyex" user authentication method described in Section 4, or does not intend to use that method in conjunction with the GSS-API context established during key exchange, then anon_req_flag SHOULD be set to "true". Otherwise, this flag MAY be set to true if the client wishes to hide its identity. Since the key exchange process will involve the exchange of only a single token once the context has been established, it is not necessary that the GSS-API context support detection of replayed or out-of-sequence tokens. Thus, replay_det_req_flag and sequence_req_flag need not be set for this process. These flags SHOULD be set to "false".
2. Cがあれば、この交換の間Sから受信した最新の応答トークンを使用して、もしGSS_Init_sec_context（）を呼び出します。この呼び出しのために、クライアントは、相互認証が実行されることを要求するために、「真」にmutual_req_flagを設定しなければなりません。また、メッセージごとの完全性保護は、このコンテキストのためにサポートすることを要求するために、「真」にinteg_req_flag設定しなければなりません。また、deleg_req_flagは、ユーザによって要求された場合、アクセスの委任を要求するために、「真」に設定されるかもしれません。鍵交換プロセスのみがホストを認証するので、anon_req_flagの設定は、このプロセスに重要ではありません。クライアントは、セクション4に記載された「GSSAPI-keyex」ユーザ認証方式をサポートしていない、または鍵交換中に確立GSS-APIコンテキストと連動して、そのメソッドを使用するつもりはありません、そしてanon_req_flagは「真」に設定する必要がある場合。クライアントがその身元を隠すことを希望する場合それ以外の場合、このフラグをtrueに設定されるかもしれません。コンテキストが確立された後、鍵交換プロセスは、単一のトークンの交換を含むので、それは必要ではないことを再生またはアウトオブシーケンストークンのGSS-APIコンテキストサポート検出。したがって、replay_det_req_flagとsequence_req_flagは、このプロセスのために設定する必要はありません。これらのフラグは「偽」に設定する必要があります。
* If the resulting major_status code is GSS_S_COMPLETE and the
mutual_state flag is not true, then mutual authentication has
not been established, and the key exchange MUST fail.
* If the resulting major_status code is GSS_S_COMPLETE and the integ_avail flag is not true, then per-message integrity protection is not available, and the key exchange MUST fail.
*結果major_statusコードがGSS_S_COMPLETEで、integ_availフラグが真でない場合は、メッセージごとの完全性保護が利用できず、鍵交換が失敗しなければなりません。
* If the resulting major_status code is GSS_S_COMPLETE and both the mutual_state and integ_avail flags are true, the resulting output token is sent to S.
得major_statusコードがGSS_S_COMPLETEでありmutual_stateとinteg_availフラグの両方が真である場合*、結果の出力トークンは、Sに送信されます
* If the resulting major_status code is GSS_S_CONTINUE_NEEDED, the output_token is sent to S, which will reply with a new token to be provided to GSS_Init_sec_context().
得major_statusコードがGSS_S_CONTINUE_NEEDED場合*たoutput_tokenは、もしGSS_Init_sec_context（に提供する新しいトークン）で応答れる、Sに送信されます。
* The client MUST also include "e" with the first message it sends to the server during this process; if the server receives more than one "e" or none at all, the key exchange fails.
*クライアントはまた、このプロセスの間にサーバーに送信する最初のメッセージで「e」を含まなければなりません。サーバーがすべてで、複数の「E」またはnoneを受信した場合、鍵交換が失敗します。
* It is an error if the call does not produce a token of non-zero length to be sent to the server. In this case, the key exchange MUST fail.
*これは、呼び出しがサーバーに送信されるように非ゼロの長さのトークンを生成しない場合は、エラーがあります。この場合、鍵交換が失敗しなければなりません。
3. S calls GSS_Accept_sec_context(), using the token received from C.
3. Sは場合gss_accept_sec_context（）は、Cから受信したトークンを使用して、呼び出し
* If the resulting major_status code is GSS_S_COMPLETE and the
mutual_state flag is not true, then mutual authentication has
not been established, and the key exchange MUST fail.
* If the resulting major_status code is GSS_S_COMPLETE and the integ_avail flag is not true, then per-message integrity protection is not available, and the key exchange MUST fail.
*結果major_statusコードがGSS_S_COMPLETEで、integ_availフラグが真でない場合は、メッセージごとの完全性保護が利用できず、鍵交換が失敗しなければなりません。
* If the resulting major_status code is GSS_S_COMPLETE and both the mutual_state and integ_avail flags are true, then the security context has been established, and processing continues with step 4.
得major_statusコードがGSS_S_COMPLETEでありmutual_stateとinteg_availフラグの両方が真である場合*は、セキュリティコンテキストが確立されている、処理はステップ4に続きます。
* If the resulting major_status code is GSS_S_CONTINUE_NEEDED, then the output token is sent to C, and processing continues with step 2.
得major_statusコードがGSS_S_CONTINUE_NEEDED場合*、出力トークンがCに送られ、処理は、ステップ2で継続されます。
* If the resulting major_status code is GSS_S_COMPLETE, but a non-zero-length reply token is returned, then that token is sent to the client.
得major_statusコードがGSS_S_COMPLETEであるが、非ゼロ長応答トークンが返された場合*、そのトークンがクライアントに送信されます。
4. S generates a random number y (0 < y < q) and computes f = g^y mod p. It computes K = e ^ y mod p, and H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K). It then calls GSS_GetMIC() to obtain a GSS-API message integrity code for H. S then sends f and the message integrity code (MIC) to C.
4. Sは、乱数yを（0 <Y <Q）を生成すると、F = G ^ Yのmod Pを計算します。これは、K = E ^ Yのmod Pを計算し、そしてH =ハッシュ（V_C || || V_S I_C || || I_S K_S || E || F || K）。これは、次いでCにFとメッセージ完全性コード（MIC）を送信H. S用のGSS-APIメッセージインテグリティコードを取得するためにGSS_GetMIC（）を呼び出し
5. This step is performed only (1) if the server's final call to GSS_Accept_sec_context() produced a non-zero-length final reply token to be sent to the client and (2) if no previous call by the client to GSS_Init_sec_context() has resulted in a major_status of GSS_S_COMPLETE. Under these conditions, the client makes an additional call to GSS_Init_sec_context() to process the final reply token. This call is made exactly as described above. However, if the resulting major_status is anything other than GSS_S_COMPLETE, or a non-zero-length token is returned, it is an error and the key exchange MUST fail.
5.このステップのみ（1）場合gss_accept_sec_context（のサーバーの最後の呼び出し場合に実行される）クライアントに送信する非ゼロ長最終応答トークンを生成し、（2））もしGSS_Init_sec_contextにクライアントによって以前の呼び出し（IF GSS_S_COMPLETEのmajor_statusをもたらしました。これらの条件下では、クライアントが追加もしGSS_Init_sec_context（）への呼び出し、最終的な回答トークンを処理するためになります。前述したように、このコールは正確に行われています。得major_statusがGSS_S_COMPLETE以外である、または非ゼロ長トークンが返された場合は、それはエラーであり、鍵交換が失敗しなければなりません。
6. C computes K = f^x mod p, and H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K). It then calls GSS_VerifyMIC() to verify that the MIC sent by S matches H. If the MIC is not successfully verified, the key exchange MUST fail.
6. Cは、K = F ^ Xのmod Pを計算し、そしてH =ハッシュ（V_C || || V_S I_C || || I_S K_S || E || F || K）。その後、MICが正常に確認されていない場合はSによって送られたMICはH.に一致し、鍵交換が失敗しなければなりませんことを確認するためにGSS_VerifyMIC（）を呼び出します。
Either side MUST NOT send or accept e or f values that are not in the range [1, p-1]. If this condition is violated, the key exchange fails.
どちらの側が送信または範囲内にないEまたはFの値[1、P-1]を受け入れてはいけません。この条件に違反した場合、鍵交換が失敗します。
If any call to GSS_Init_sec_context() or GSS_Accept_sec_context() returns a major_status other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, or any other GSS-API call returns a major_status other than GSS_S_COMPLETE, the key exchange fails. In this case, several mechanisms are available for communicating error information to the peer before terminating the connection as required by [SSH-TRANSPORT]:
もしGSS_Init_sec_context（）またはのgss_accept_sec_context（）への呼び出しがGSS_S_COMPLETEまたはGSS_S_CONTINUE_NEEDED以外のmajor_statusを返す、または任意の他のGSS-APIの呼び出しがGSS_S_COMPLETE以外のmajor_statusを返し、鍵交換が失敗した場合。この場合には、いくつかのメカニズムが[SSH-TRANSPORT]によって要求される接続を終了する前にピアにエラー情報を通信するために利用可能です。
o If the key exchange fails due to any GSS-API error on the server (including errors returned by GSS_Accept_sec_context()), the server MAY send a message informing the client of the details of the error. In this case, if an error token is also sent (see below), then this message MUST be sent before the error token.
鍵交換が原因サーバー上の任意のGSS-APIエラーのために失敗した場合、O（場合gss_accept_sec_contextによって返されたエラーを含む（））、サーバは、エラーの詳細をクライアントに通知するメッセージを送信することができます。エラートークンはまた、（下記参照）が送られる場合は、この場合には、このメッセージは、エラートークンの前に送信されなければなりません。
o If the key exchange fails due to a GSS-API error returned from the server's call to GSS_Accept_sec_context(), and an "error token" is also returned, then the server SHOULD send the error token to the client to allow completion of the GSS security exchange.
鍵交換は、GSS-APIエラーが場合gss_accept_sec_context（）へのサーバーの呼び出しから返され、「エラートークン」も返される原因に失敗した場合は、O、サーバはGSSの完了を許可するようにクライアントにエラー・トークンを送るべきですセキュリティ交換。
o If the key exchange fails due to a GSS-API error returned from the client's call to GSS_Init_sec_context(), and an "error token" is also returned, then the client SHOULD send the error token to the server to allow completion of the GSS security exchange.
鍵交換は、GSS-APIエラーがもしGSS_Init_sec_context（）へのクライアントの呼び出しから返され、「エラートークン」も返される原因に失敗した場合は、O、クライアントはGSSの完了を可能にするために、サーバーにエラートークンを送るべきですセキュリティ交換。
As noted in Section 9, it may be desirable under site security policy to obscure information about the precise nature of the error; thus, it is RECOMMENDED that implementations provide a method to suppress these messages as a matter of policy.
第9章で述べたように、それはエラーの正確な性質についての情報を分かりにくくするために、サイトのセキュリティポリシーの下が望ましいかもしれません。したがって、実装はポリシーの問題として、これらのメッセージを抑制するための方法を提供することが推奨されています。
This is implemented with the following messages. The hash algorithm for computing the exchange hash is defined by the method name, and is called HASH. The group used for Diffie-Hellman key exchange and the underlying GSS-API mechanism are also defined by the method name.
これは、次のようなメッセージで実装されています。交換ハッシュを計算するハッシュアルゴリズムは、メソッド名によって定義され、HASHと呼ばれています。 Diffie-Hellman鍵交換と基本的なGSS-APIメカニズムのために使用されるグループは、メソッド名で定義されています。
After the client's first call to GSS_Init_sec_context(), it sends the following:
もしGSS_Init_sec_context（）へのクライアントの最初の呼び出しの後、それは次のように送信します。
byte SSH_MSG_KEXGSS_INIT
string output_token (from GSS_Init_sec_context())
mpint e
Upon receiving the SSH_MSG_KEXGSS_INIT message, the server MAY send the following message, prior to any other messages, to inform the client of its host key.
SSH_MSG_KEXGSS_INITメッセージを受信すると、サーバーは、そのホスト鍵をクライアントに通知するために、前に他のメッセージに、以下のメッセージを送信することができます。
byte SSH_MSG_KEXGSS_HOSTKEY
string server public host key and certificates (K_S)
Since this key exchange method does not require the host key to be used for any encryption operations, this message is OPTIONAL. If the "null" host key algorithm described in Section 5 is used, this message MUST NOT be sent. If this message is sent, the server public host key(s) and/or certificate(s) in this message are encoded as a single string, in the format specified by the public key type in use (see [SSH-TRANSPORT], Section 6.6).
この鍵交換方法は、任意の暗号化操作に使用するホストキーを必要としないので、このメッセージはオプションです。第5節で説明した「ヌル」ホスト鍵アルゴリズムを使用する場合は、このメッセージを送ってはいけません。このメッセージが送信された場合、このメッセージ内のサーバホスト公開鍵（単数または複数）および/または証明書（複数可）、[SSH-TRANSPORT]を参照（使用中の公開鍵のタイプによって指定された形式で、1つの文字列として符号化されます6.6節）。
In traditional SSH deployments, host keys are normally expected to change infrequently, and there is often no mechanism for validating host keys not already known to the client. As a result, the use of a new host key by an already-known host is usually considered an indication of a possible man-in-the-middle attack, and clients often present strong warnings and/or abort the connection in such cases.
伝統的なSSHの展開では、ホストキーは通常、まれに変更することが期待され、すでにクライアントに知られていないホスト鍵を検証するためのメカニズムがあることが多いされていません。その結果、既に知られているホストによって、新しいホストキーを使用することは通常可能man-in-the-middle攻撃の兆候とみなされ、そしてクライアントが頻繁に強い警告を提示し、および/またはそのような場合に接続を中止します。
By contrast, when GSS-API-based key exchange is used, host keys sent via the SSH_MSG_KEXGSS_HOSTKEY message are authenticated as part of the GSS-API key exchange, even when previously unknown to the client. Further, in environments in which GSS-API-based key exchange is used heavily, it is possible and even likely that host keys will change much more frequently and/or without advance warning.
これとは対照的に、GSS-APIベースの鍵交換を使用した場合、SSH_MSG_KEXGSS_HOSTKEYメッセージを介して送信されたホスト鍵はクライアントにしても、以前に未知の、GSS-APIキー交換の一環として認証されています。さらに、GSS-APIベースの鍵交換が頻繁に使用されている環境では、ホスト鍵が頻繁および/または事前の警告なしにはるかに変更される可能性もありそうです。
Therefore, when a new key for an already-known host is received via the SSH_MSG_KEXGSS_HOSTKEY message, clients SHOULD NOT issue strong warnings or abort the connection, provided the GSS-API-based key exchange succeeds.
すでに知られているホストのための新しいキーがSSH_MSG_KEXGSS_HOSTKEYメッセージを介して受信したときにそのため、クライアントは強い警告を発行するか、接続を中止してはなりません、GSS-APIベースの鍵交換が成功しました。
In order to facilitate key re-exchange after the user's GSS-API credentials have expired, client implementations SHOULD store host keys received via SSH_MSG_KEXGSS_HOSTKEY for the duration of the session, even when such keys are not stored for long-term use.
ユーザーのGSS-API資格の有効期限が切れた後にキー再交換を容易にするために、クライアントの実装は、そのようなキーが長期使用のために保存されていない場合でも、セッションの間SSH_MSG_KEXGSS_HOSTKEY介して受信したホスト鍵を格納する必要があります。
Each time the server's call to GSS_Accept_sec_context() returns a major_status code of GSS_S_CONTINUE_NEEDED, it sends the following reply to the client:
場合gss_accept_sec_context（）へのサーバーの呼び出しがGSS_S_CONTINUE_NEEDEDのmajor_statusコードを返すたびに、クライアントに次の応答を送信します。
byte SSH_MSG_KEXGSS_CONTINUE
string output_token (from GSS_Accept_sec_context())
If the client receives this message after a call to GSS_Init_sec_context() has returned a major_status code of GSS_S_COMPLETE, a protocol error has occurred and the key exchange MUST fail.
クライアントがGSS_S_COMPLETEのmajor_statusコードを返しました（）もしGSS_Init_sec_contextの呼び出し後、このメッセージを受信した場合、プロトコルエラーが発生したとの鍵交換が失敗しなければなりません。
Each time the client receives the message described above, it makes another call to GSS_Init_sec_context(). It then sends the following:
クライアントは、上記のメッセージを受信するたびに、それは）（もしGSS_Init_sec_contextへの別の呼び出しを行います。その後、次を送信します。
byte SSH_MSG_KEXGSS_CONTINUE
string output_token (from GSS_Init_sec_context())
The server and client continue to trade these two messages as long as the server's calls to GSS_Accept_sec_context() result in major_status codes of GSS_S_CONTINUE_NEEDED. When a call results in a major_status code of GSS_S_COMPLETE, it sends one of two final messages.
サーバとクライアントは、限りのgss_accept_sec_contextに、サーバーの呼び出しは（）GSS_S_CONTINUE_NEEDEDのmajor_statusコードにつながるように、これらの2つのメッセージを交換し続けます。 GSS_S_COMPLETEのmajor_statusコード内の場合は、コールの結果、それは2つの最終メッセージのいずれかを送信します。
If the server's final call to GSS_Accept_sec_context() (resulting in a major_status code of GSS_S_COMPLETE) returns a non-zero-length token to be sent to the client, it sends the following:
場合gss_accept_sec_context（）（GSS_S_COMPLETEのmajor_statusコードが得られる）に、サーバの最後の呼び出しがクライアントに送信するトークン非ゼロの長さを返した場合、それは次のように送信します。
byte SSH_MSG_KEXGSS_COMPLETE
mpint f
string per_msg_token (MIC of H)
boolean TRUE
string output_token (from GSS_Accept_sec_context())
If the client receives this message after a call to GSS_Init_sec_context() has returned a major_status code of GSS_S_COMPLETE, a protocol error has occurred and the key exchange MUST fail.
クライアントがGSS_S_COMPLETEのmajor_statusコードを返しました（）もしGSS_Init_sec_contextの呼び出し後、このメッセージを受信した場合、プロトコルエラーが発生したとの鍵交換が失敗しなければなりません。
If the server's final call to GSS_Accept_sec_context() (resulting in a major_status code of GSS_S_COMPLETE) returns a zero-length token or no token at all, it sends the following:
場合gss_accept_sec_context（）（GSS_S_COMPLETEのmajor_statusコードで得られた）に、サーバーの最終呼がゼロ長トークンまたは全くトークンを返す場合、それは、以下を送信します。
byte SSH_MSG_KEXGSS_COMPLETE
mpint f
string per_msg_token (MIC of H)
boolean FALSE
If the client receives this message when no call to GSS_Init_sec_context() has yet resulted in a major_status code of GSS_S_COMPLETE, a protocol error has occurred and the key exchange MUST fail.
もしGSS_Init_sec_contextへの呼び出しは（）まだGSS_S_COMPLETEのmajor_statusコードをもたらさなかったときに、クライアントは、このメッセージを受信した場合、プロトコルエラーが発生したとの鍵交換が失敗しなければなりません。
If either the client's call to GSS_Init_sec_context() or the server's call to GSS_Accept_sec_context() returns an error status and produces an output token (called an "error token"), then the following SHOULD be sent to convey the error information to the peer:
もしGSS_Init_sec_context（へのクライアントのいずれかの呼び出し）または場合gss_accept_sec_context（へのサーバーの呼び出しが）エラー状態を返し、（「トークンエラー」と呼ばれる）の出力トークンを生成する場合、次のピアにエラー情報を伝えるために送ってください：
byte SSH_MSG_KEXGSS_CONTINUE
string error_token
If a server sends both this message and an SSH_MSG_KEXGSS_ERROR message, the SSH_MSG_KEXGSS_ERROR message MUST be sent first, to allow clients to record and/or display the error information before processing the error token. This is important because a client processing an error token will likely disconnect without reading any further messages.
サーバは、このメッセージとSSH_MSG_KEXGSS_ERRORメッセージの両方を送信する場合、SSH_MSG_KEXGSS_ERRORメッセージは、クライアントがエラートークンを処理する前に、エラー情報を記録および/または表示できるようにするために、最初に送信されなければなりません。エラー・トークンを処理し、クライアントはおそらくそれ以上のメッセージを読まずに切断されますので、これは重要です。
In the event of a GSS-API error on the server, the server MAY send the following message before terminating the connection:
サーバー上のGSS-APIエラーが発生した場合、サーバーは接続を終了する前に、次のメッセージを送信することができます。
byte SSH_MSG_KEXGSS_ERROR
uint32 major_status
uint32 minor_status
string message
string language tag
The message text MUST be encoded in the UTF-8 encoding described in [UTF8]. Language tags are those described in [LANGTAG]. Note that the message text may contain multiple lines separated by carriage return-line feed (CRLF) sequences. Application developers should take this into account when displaying these messages.
メッセージテキストは、[UTF8]に記載のUTF8エンコーディングでエンコードされなければなりません。言語タグは、[LANGTAG]に記載されているものです。メッセージテキストはキャリッジリターンラインフィード（CRLF）配列によって分離された複数の行を含んでいてもよいことに留意されたいです。これらのメッセージを表示するときにアプリケーション開発者は、このことを考慮すべきです。
The hash H is computed as the HASH hash of the concatenation of the following:
ハッシュHは、以下の連結のハッシュハッシュとして計算されます。
string V_C, the client's version string (CR, NL excluded)
string V_S, the server's version string (CR, NL excluded)
string I_C, the payload of the client's SSH_MSG_KEXINIT
string I_S, the payload of the server's SSH_MSG_KEXINIT
string K_S, the host key
mpint e, exchange value sent by the client
mpint f, exchange value sent by the server
mpint K, the shared secret
This value is called the exchange hash, and it is used to authenticate the key exchange. The exchange hash SHOULD be kept secret. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the server or received by the client, then the empty string is used in place of K_S when computing the exchange hash.
この値は、交換ハッシュと呼ばれ、鍵交換を認証するために使用されます。交換ハッシュは秘密にされるべきです。何SSH_MSG_KEXGSS_HOSTKEYメッセージは、クライアントによって、サーバによって送信されない、または受信している場合は交換ハッシュを計算するときに、空の文字列はK_Sの代わりに使用されます。
The GSS_GetMIC call MUST be applied over H, not the original data.
GSS_GetMICコールはHではなく、元のデータの上に適用されなければなりません。
This section describes a modification to the generic GSS-API-authenticated Diffie-Hellman key exchange to allow the negotiation of the group to be used, using a method based on that described in [GROUP-EXCHANGE].
このセクションでは、[GROUP-EXCHANGE]に記載されたものに基づく方法を使用して、グループのネゴシエーションが使用されることを可能にするために、一般的なGSS-API認証のDiffie-Hellman鍵交換に変更を記載しています。
The server keeps a list of safe primes and corresponding generators that it can select from. These are chosen as described in Section 3 of [GROUP-EXCHANGE]. The client requests a modulus from the server, indicating the minimum, maximum, and preferred sizes; the server responds with a suitable modulus and generator. The exchange then proceeds as described in Section 2.1 above.
サーバーは安全素数と、それはから選択することができ、対応するジェネレータのリストを保持します。 [GROUP-EXCHANGE]のセクション3に記載されているように、これらは、選択されます。クライアントは、最小値、最大値、および好ましいサイズを示す、サーバから弾性率を要求します。サーバーは、適切な弾性率及び発電機で応答します。上記セクション2.1に記載したように交換が次に進みます。
This description uses the following symbols, in addition to those defined above:
この説明は、上記で定義されたものに加えて、以下の記号を使用します：
o n is the size of the modulus p in bits that the client would like to receive from the server
O nは、クライアントがサーバから受信したいビットで係数pのサイズであります
o min and max are the minimal and maximal sizes of p in bits that are acceptable to the client
O minとmaxは、クライアントに許容されるビットのpの最小と最大のサイズです
1. C sends "min || n || max" to S, indicating the minimal acceptable group size, the preferred size of the group, and the maximal group size in bits the client will accept.
1. Cは最小許容グループサイズ、グループの好ましいサイズ、およびクライアントが受け入れるビットの最大群サイズを示す、Sに「分|| N ||マックス」を送信します。
2. S finds a group that best matches the client's request, and sends "p || g" to C.
2. Sが最高のクライアントの要求に合致するグループを見つけ、Cに「p個の|| gを」送ります
3. The exchange proceeds as described in Section 2.1 above, beginning with step 1, except that the exchange hash is computed as described below.
3.交換進み、上記セクション2.1に記載したように、以下に説明するように交換ハッシュが計算されることを除いて、ステップ1から始まります。
Servers and clients SHOULD support groups with a modulus length of k bits, where 1024 <= k <= 8192. The recommended values for min and max are 1024 and 8192, respectively.
サーバとクライアントは、minとmax 1024 <= K <= 8192推奨値は、それぞれ1024および8192であるkビットのモジュラスの長さを持つグループをサポートしなければなりません。
This is implemented using the following messages, in addition to those described above:
これは、上述したものに加えて、以下のメッセージを使用して実装されます。
First, the client sends:
まず、クライアントが送信します。
byte SSH_MSG_KEXGSS_GROUPREQ
uint32 min, minimal size in bits of an acceptable group
uint32 n, preferred size in bits of the group the server
should send
uint32 max, maximal size in bits of an acceptable group
The server responds with:
サーバがで応答します。
byte SSH_MSG_KEXGSS_GROUP
mpint p, safe prime
mpint g, generator for subgroup in GF(p)
This is followed by the message exchange described above in Section 2.1, except that the exchange hash H is computed as the HASH hash of the concatenation of the following:
これは交換ハッシュHは、以下の連結のハッシュハッシュとして計算されることを除いて、セクション2.1で上記メッセージ交換が続きます。
string V_C, the client's version string (CR, NL excluded)
string V_S, the server's version string (CR, NL excluded)
string I_C, the payload of the client's SSH_MSG_KEXINIT
string I_S, the payload of the server's SSH_MSG_KEXINIT
string K_S, the host key
uint32 min, minimal size in bits of an acceptable group
uint32 n, preferred size in bits of the group the server
should send
uint32 max, maximal size in bits of an acceptable group
mpint p, safe prime
mpint g, generator for subgroup in GF(p)
mpint e, exchange value sent by the client
mpint f, exchange value sent by the server
mpint K, the shared secret
Each of these methods specifies GSS-API-authenticated Diffie-Hellman key exchange as described in Section 2.1 with SHA-1 as HASH, and the group defined in Section 8.1 of [SSH-TRANSPORT]. The method name for each method is the concatenation of the string "gss-group1-sha1-" with the Base64 encoding of the MD5 hash [MD5] of the ASN.1 Distinguished Encoding Rules (DER) encoding [ASN1] of the underlying GSS-API mechanism's Object Identifier (OID). Base64 encoding is described in Section 6.8 of [MIME].
これらの方法のそれぞれは、ハッシュとしてSHA-1のセクション2.1に記載したようにGSS-API認証のDiffie-Hellman鍵交換を指定し、そして[SSH-TRANSPORT]のセクション8.1で定義されたグループ。下地GSSの[ASN1]コードASN.1識別符号化規則（DER）の各メソッドのメソッド名MD5ハッシュのBase64エンコードした文字列「GSS-GROUP1-sha1-」を連結したものである[MD5] -API機構のオブジェクト識別子（OID）。 Base64エンコードは、[MIME]のセクション6.8に記載されています。
Each and every such key exchange method is implicitly registered by this specification. The IESG is considered to be the owner of all such key exchange methods; this does NOT imply that the IESG is considered to be the owner of the underlying GSS-API mechanism.
一人ひとり、そのような鍵交換方式は、暗黙的にこの仕様で登録されています。 IESGは、すべてのそのような鍵交換方法の所有者であると考えられます。これはIESGが根底にあるGSS-API機構の所有者であると考えられていることを意味しません。
Each of these methods specifies GSS-API authenticated Diffie-Hellman key exchange as described in Section 2.1 with SHA-1 as HASH, and the group defined in Section 8.2 of [SSH-TRANSPORT]. The method name for each method is the concatenation of the string "gss-group14-sha1-" with the Base64 encoding of the MD5 hash [MD5] of the ASN.1 DER encoding [ASN1] of the underlying GSS-API mechanism's OID. Base64 encoding is described in Section 6.8 of [MIME].
これらの方法の各々は、GSS-APIは、ハッシュとしてSHA-1のセクション2.1に記載したようにDiffie-Hellman鍵交換を認証し、そして[SSH-TRANSPORT]のセクション8.2で定義されたグループを指定します。各メソッドのメソッド名は、基礎となるGSS-API機構のOIDのASN.1 DERエンコーディング[ASN1]のMD5ハッシュ[MD5]のBase64エンコーディングと「GSS-group14-sha1-」文字列の連結です。 Base64エンコードは、[MIME]のセクション6.8に記載されています。
Each and every such key exchange method is implicitly registered by this specification. The IESG is considered to be the owner of all such key exchange methods; this does NOT imply that the IESG is considered to be the owner of the underlying GSS-API mechanism.
一人ひとり、そのような鍵交換方式は、暗黙的にこの仕様で登録されています。 IESGは、すべてのそのような鍵交換方法の所有者であると考えられます。これはIESGが根底にあるGSS-API機構の所有者であると考えられていることを意味しません。
Each of these methods specifies GSS-API-authenticated Diffie-Hellman key exchange as described in Section 2.2 with SHA-1 as HASH. The method name for each method is the concatenation of the string "gss-gex-sha1-" with the Base64 encoding of the MD5 hash [MD5] of the ASN.1 DER encoding [ASN1] of the underlying GSS-API mechanism's OID. Base64 encoding is described in Section 6.8 of [MIME].
ハッシュとしてSHA-1のセクション2.2に記載したように、これらの方法の各々は、GSS-API認証のDiffie-Hellman鍵交換を指定します。各メソッドのメソッド名は、基礎となるGSS-API機構のOIDのASN.1 DERエンコーディング[ASN1]のMD5ハッシュ[MD5]のBase64エンコーディングと「GSS-GEX-sha1-」文字列の連結です。 Base64エンコードは、[MIME]のセクション6.8に記載されています。
Each and every such key exchange method is implicitly registered by this specification. The IESG is considered to be the owner of all such key exchange methods; this does NOT imply that the IESG is considered to be the owner of the underlying GSS-API mechanism.
一人ひとり、そのような鍵交換方式は、暗黙的にこの仕様で登録されています。 IESGは、すべてのそのような鍵交換方法の所有者であると考えられます。これはIESGが根底にあるGSS-API機構の所有者であると考えられていることを意味しません。
Key exchange method names starting with "gss-" are reserved for key exchange methods that conform to this document; in particular, for those methods that use the GSS-API-authenticated Diffie-Hellman key exchange algorithm described in Section 2.1, including any future methods that use different groups and/or hash functions. The intent is that the names for any such future methods be defined in a similar manner to that used in Section 2.3.
「gss-」で始まる鍵交換メソッド名は、本文書に準拠して鍵交換方式のために予約されています。特に、異なるグループおよび/またはハッシュ関数を使用するすべての将来の方法を含む、セクション2.1に記載のGSS-API認証Diffie-Hellman鍵交換アルゴリズムを使用するこれらの方法のために。目的は、このような将来のメソッドの名前が2.3節で用いたものと同様に定義されることがあります。
This section describes a general-purpose user authentication method based on [GSSAPI]. It is intended to be run over the SSH user authentication protocol [SSH-USERAUTH].
このセクションでは、[GSSAPI]に基づいて、汎用のユーザ認証方法を説明します。 SSHユーザ認証プロトコル[SSH-USERAUTH]上で実行されることを意図しています。
The authentication method name for this protocol is "gssapi-with-mic".
このプロトコルのための認証方法名は「GSSAPI-と-MIC」です。
GSS-API authentication must maintain a context. Authentication begins when the client sends an SSH_MSG_USERAUTH_REQUEST, which specifies the mechanism OIDs the client supports.
GSS-API認証は、コンテキストを維持する必要があります。クライアントは、クライアントがサポートするメカニズムのOIDを指定するSSH_MSG_USERAUTH_REQUESTを送信するときに認証が開始されます。
If the server supports any of the requested mechanism OIDs, the server sends an SSH_MSG_USERAUTH_GSSAPI_RESPONSE message containing the mechanism OID.
サーバは要求されたメカニズムのOIDのいずれかをサポートしている場合、サーバーは、機構OIDを含むSSH_MSG_USERAUTH_GSSAPI_RESPONSEメッセージを送信します。
After the client receives SSH_MSG_USERAUTH_GSSAPI_RESPONSE, the client and server exchange SSH_MSG_USERAUTH_GSSAPI_TOKEN packets until the authentication mechanism either succeeds or fails.
クライアントが認証機構までSSH_MSG_USERAUTH_GSSAPI_RESPONSE、クライアントとサーバーの交換SSH_MSG_USERAUTH_GSSAPI_TOKENパケットを受信した後に成功するか失敗するかのいずれか。
If at any time during the exchange the client sends a new SSH_MSG_USERAUTH_REQUEST packet, the GSS-API context is completely discarded and destroyed, and any further GSS-API authentication MUST restart from the beginning.
交換中いつでも、クライアントが新しいSSH_MSG_USERAUTH_REQUESTパケットを送信した場合、GSS-APIコンテキストが完全に破棄され、破壊、及び任意の更なるGSS-API認証を最初から再開する必要があります。
If the authentication succeeds and a non-empty user name is presented by the client, the SSH server implementation verifies that the user name is authorized based on the credentials exchanged in the GSS-API exchange. If the user name is not authorized, then the authentication MUST fail.
認証が成功し、非空のユーザー名がクライアントによって提示された場合、SSHサーバの実装には、ユーザー名はGSS-APIの交換で交換された資格情報に基づいて許可されていることを確認します。ユーザー名が許可されていない場合、認証は失敗しなければなりません。
The GSS-API authentication method is initiated when the client sends an SSH_MSG_USERAUTH_REQUEST:
クライアントがSSH_MSG_USERAUTH_REQUESTを送信するときにGSS-APIの認証方法が開始されます。
byte SSH_MSG_USERAUTH_REQUEST
string user name (in ISO-10646 UTF-8 encoding)
string service name (in US-ASCII)
string "gssapi-with-mic" (US-ASCII method name)
uint32 n, the number of mechanism OIDs client supports
string[n] mechanism OIDs
Mechanism OIDs are encoded according to the ASN.1 Distinguished Encoding Rules (DER), as described in [ASN1] and in Section 3.1 of
[ASN1]でのセクション3.1に記載されるように機構OIDは、ASN.1の識別符号化規則（DER）に従って符号化されます
[GSSAPI]. The mechanism OIDs MUST be listed in order of preference, and the server must choose the first mechanism OID on the list that it supports.
[GSSAPI]。メカニズムのOIDは、優先順に記載されている必要があり、サーバはそれがサポートするリストの最初の機構OIDを選択する必要があります。
The client SHOULD send GSS-API mechanism OIDs only for mechanisms that are of the same priority, compared to non-GSS-API authentication methods. Otherwise, authentication methods may be executed out of order. Thus, the client could first send an SSH_MSG_USERAUTH_REQUEST for one GSS-API mechanism, then try public key authentication, and then try another GSS-API mechanism.
クライアントは、唯一の非GSS-APIの認証方法と比較して、同じ優先順位のあるメカニズムのためのGSS-API機構のOIDを送るべきです。そうでない場合は、認証方法は、順不同で実行することができます。したがって、クライアントは、第1の公開鍵認証を試行し、1 GSS-API機構にSSH_MSG_USERAUTH_REQUESTを送信した後、別のGSS-APIメカニズムを試みることができます。
If the server does not support any of the specified OIDs, the server MUST fail the request by sending an SSH_MSG_USERAUTH_FAILURE packet.
サーバーは、指定されたOIDのいずれかをサポートしていない場合、サーバーはSSH_MSG_USERAUTH_FAILUREパケットを送信することにより、要求に失敗しなければなりません。
The user name may be an empty string if it can be deduced from the results of the GSS-API authentication. If the user name is not empty, and the requested user does not exist, the server MAY disconnect or MAY send a bogus list of acceptable authentications but never accept any. This makes it possible for the server to avoid disclosing information about which accounts exist. In any case, if the user does not exist, the authentication request MUST NOT be accepted.
それはGSS-API認証の結果から推定することができる場合は、ユーザー名が空の文字列かもしれません。ユーザ名が空でない、と要求したユーザーが存在しない場合、サーバーは接続を切断したり許容できる認証の偽のリストを送るかもしれませんが、いずれかを受け入れることはありません。これにより、サーバはアカウントが存在するかについての情報を開示することを避けるようになります。ユーザーが存在しない場合はどのような場合には、認証要求を受け入れてはなりません。
Note that the 'user name' value is encoded in ISO-10646 UTF-8. It is up to the server how it interprets the user name and determines whether the client is authorized based on his GSS-API credentials. In particular, the encoding used by the system for user names is a matter for the ssh server implementation. However, if the client reads the user name in some other encoding (e.g., ISO 8859-1 - ISO Latin1), it MUST convert the user name to ISO-10646 UTF-8 before transmitting, and the server MUST convert the user name to the encoding used on that system for user names.
「ユーザー名」の値がISO-10646 UTF-8でエンコードされていることに注意してください。それは、ユーザー名を解釈し、クライアントが自分のGSS-API資格に基づいて認可されているかどうかを決定する方法サーバー次第です。具体的には、ユーザ名にシステムによって使用される符号化は、SSHサーバー実装の問題です。クライアントは、他のいくつかのエンコーディングでユーザー名を読み込む場合は、（例えば、ISO 8859-1 - ISO Latin1の）、それは、送信する前にISO-10646 UTF-8にユーザ名を変換する必要があり、サーバはにユーザー名を変換する必要がありますユーザー名のために、そのシステム上で使用するエンコーディング。
Any normalization or other preparation of names is done by the ssh server based on the requirements of the system, and is outside the scope of SSH. SSH implementations which maintain private user databases SHOULD prepare user names as described by [SASLPREP].
名前の任意の正規化または他の製剤には、システムの要件に基づいてSSHサーバによって行われ、SSHの範囲外です。 【SASLPREP]により記載されたように、プライベートユーザデータベースを維持するSSHの実装では、ユーザ名を準備する必要があります。
The client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST abandon the previous authentication attempt and continue with the new one.
クライアントは、任意の時点でサーバが以前の認証の試みを捨てて新しいものを継続しなければならない場合には、新たなSSH_MSG_USERAUTH_REQUESTメッセージ、で継続してもよいです。
The server responds to the SSH_MSG_USERAUTH_REQUEST with either an SSH_MSG_USERAUTH_FAILURE if none of the mechanisms are supported or with an SSH_MSG_USERAUTH_GSSAPI_RESPONSE as follows:
メカニズムのいずれもサポートされていないかSSH_MSG_USERAUTH_GSSAPI_RESPONSEとされている場合は、次のようにサーバがSSH_MSG_USERAUTH_FAILUREどちらかとSSH_MSG_USERAUTH_REQUESTに応答します。
byte SSH_MSG_USERAUTH_GSSAPI_RESPONSE
string selected mechanism OID
The mechanism OID must be one of the OIDs sent by the client in the SSH_MSG_USERAUTH_REQUEST packet.
機構OIDはSSH_MSG_USERAUTH_REQUESTパケットでクライアントから送信されたOIDのいずれかでなければなりません。
Once the mechanism OID has been selected, the client will then initiate an exchange of one or more pairs of SSH_MSG_USERAUTH_GSSAPI_TOKEN packets. These packets contain the tokens produced from the 'GSS_Init_sec_context()' and 'GSS_Accept_sec_context()' calls. The actual number of packets exchanged is determined by the underlying GSS-API mechanism.
機構OIDが選択されると、クライアントは次にSSH_MSG_USERAUTH_GSSAPI_TOKENパケットの1以上のペアの交換を開始します。これらのパケットは、「もしGSS_Init_sec_context（）」と「のgss_accept_sec_context（）」の呼び出しから生成されたトークンが含まれています。交換されるパケットの実際の数は、基礎となるGSS-API機構によって決定されます。
byte SSH_MSG_USERAUTH_GSSAPI_TOKEN
string data returned from either GSS_Init_sec_context()
or GSS_Accept_sec_context()
If an error occurs during this exchange on server side, the server can terminate the method by sending an SSH_MSG_USERAUTH_FAILURE packet. If an error occurs on client side, the client can terminate the method by sending a new SSH_MSG_USERAUTH_REQUEST packet.
エラーがサーバー側でこの交換中に発生した場合、サーバはSSH_MSG_USERAUTH_FAILUREパケットを送信することによって、方法を終了することができます。エラーがクライアント側で発生した場合、クライアントは新しいSSH_MSG_USERAUTH_REQUESTパケットを送信することによって、メソッドを終了することができます。
When calling GSS_Init_sec_context(), the client MUST set integ_req_flag to "true" to request that per-message integrity protection be supported for this context. In addition, deleg_req_flag MAY be set to "true" to request access delegation, if requested by the user.
もしGSS_Init_sec_context（）を呼び出すとき、クライアントは、メッセージごとの完全性保護は、このコンテキストのためにサポートすることを要求するために、「真」にinteg_req_flag設定しなければなりません。また、deleg_req_flagは、ユーザによって要求された場合、アクセスの委任を要求するために、「真」に設定されるかもしれません。
Since the user authentication process by its nature authenticates only the client, the setting of mutual_req_flag is not needed for this process. This flag SHOULD be set to "false".
その性質により、ユーザ認証処理のみがクライアントを認証するので、mutual_req_flagの設定は、このプロセスは必要ありません。このフラグは「偽」に設定する必要があります。
Since the user authentication process will involve the exchange of only a single token once the context has been established, it is not necessary that the context support detection of replayed or out-of-sequence tokens. Thus, the setting of replay_det_req_flag and sequence_req_flag are not needed for this process. These flags SHOULD be set to "false".
ユーザ認証処理は、単一のトークンの交換を伴うのでコンテキストが確立されると、それはリプレイやアウトオブシーケンストークンのコンテキストサポート検出する必要はありません。したがって、replay_det_req_flagとsequence_req_flagの設定は、このプロセスには必要ありません。これらのフラグは「偽」に設定する必要があります。
Additional SSH_MSG_USERAUTH_GSSAPI_TOKEN messages are sent if and only if the calls to the GSS-API routines produce send tokens of non-zero length.
GSS-APIルーチンの呼び出しが非ゼロの長さのトークンを送って生産している場合にのみ場合は、追加SSH_MSG_USERAUTH_GSSAPI_TOKENメッセージが送信されます。
Any major status code other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED SHOULD be a failure.
GSS_S_COMPLETEまたはGSS_S_CONTINUE_NEEDED以外の主要なステータスコードは失敗であるべきです。
In some cases, it is possible to obtain improved security by allowing access only if the client sends a valid message integrity code (MIC) binding the GSS-API context to the keys used for encryption and integrity protection of the SSH session. With this extra level of protection, a "man-in-the-middle" attacker who has convinced a client of his authenticity cannot then relay user authentication messages between the real client and server, thus gaining access to the real server. This additional protection is available when the negotiated GSS-API context supports per-message integrity protection, as indicated by the setting of the integ_avail flag on successful return from GSS_Init_sec_context() or GSS_Accept_sec_context().
いくつかのケースでは、クライアントがSSHセッションの暗号化と整合性の保護のために使用されるキーにGSS-APIコンテキストを結合有効なメッセージ整合性コード（MIC）を送信した場合にのみアクセスを許可することでセキュリティの向上を得ることが可能です。保護のこの余分なレベル、彼の信憑性のクライアントが、その後ので、実サーバへのアクセスを獲得、実際のクライアントとサーバの間でユーザ認証メッセージを中継することはできません確信しました「のman-in-the-middle」攻撃を持ちます。交渉さGSS-APIのコンテキストはメッセージごとの完全性保護をサポートしているとき、もしGSS_Init_sec_context（）または場合gss_accept_sec_context（）から正常に復帰上のinteg_availフラグの設定によって示されるように、この追加の保護は、利用可能です。
When the client's call to GSS_Init_sec_context() returns GSS_S_COMPLETE with the integ_avail flag set, the client MUST conclude the user authentication exchange by sending the following message:
もしGSS_Init_sec_context（）へのクライアントの呼び出しがinteg_availフラグを設定してGSS_S_COMPLETEを返すと、クライアントは次のメッセージを送信することにより、ユーザー認証交換を締結しなければなりません：
byte SSH_MSG_USERAUTH_GSSAPI_MIC
string MIC
This message MUST be sent only if GSS_Init_sec_context() returned GSS_S_COMPLETE. If a token is also returned, then the SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one.
もしGSS_Init_sec_context（）はGSS_S_COMPLETEを返された場合にのみ、このメッセージが送られなければなりません。トークンも返される場合、SSH_MSG_USERAUTH_GSSAPI_TOKENメッセージはこの前に送らなければなりません。
The contents of the MIC field are obtained by calling GSS_GetMIC() over the following, using the GSS-API context that was just established:
MICフィールドの内容は、ちょうど設立されたGSS-APIコンテキストを使用して、以下の上GSS_GetMIC（）を呼び出すことによって得られます。
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service
string "gssapi-with-mic"
If this message is received by the server before the GSS-API context is fully established, the server MUST fail the authentication.
GSS-APIコンテキストが完全に確立される前に、このメッセージは、サーバによって受信された場合、サーバーは認証が失敗しなければなりません。
If this message is received by the server when the negotiated GSS-API context does not support per-message integrity protection, the server MUST fail the authentication.
このメッセージは、ネゴシエートGSS-APIのコンテキストはメッセージごとの完全性保護をサポートしていないサーバで受信された場合、サーバーは認証が失敗しなければなりません。
Some servers may wish to permit user authentication to proceed even when the negotiated GSS-API context does not support per-message integrity protection. In such cases, it is possible for the server to successfully complete the GSS-API method, while the client's last call to GSS_Init_sec_context() fails. If the server simply assumed success on the part of the client and completed the authentication service, it is possible that the client would fail to complete the authentication method, but not be able to retry other methods because the server had already moved on. To protect against this, a final message is sent by the client to indicate it has completed authentication.
いくつかのサーバは、ネゴシエートGSS-APIのコンテキストはメッセージごとの完全性保護をサポートしていない場合でも続行するためにユーザ認証を許可したい場合があります。サーバーが正常にGSS-APIメソッドを完了するのをもしGSS_Init_sec_contextへのクライアントの最後の（）の呼び出しが失敗しながら、このような場合には、それは、可能です。サーバは単にクライアント側での成功を仮定し、認証サービスを完了した場合、クライアントが認証方法を完了しないが、サーバーがすでに上に移動していたので、他の方法を再試行することができないであろうことは可能です。これを防ぐために、最後のメッセージは、それが認証を完了したことを示すために、クライアントによって送信されます。
When the client's call to GSS_Init_sec_context() returns GSS_S_COMPLETE with the integ_avail flag not set, the client MUST conclude the user authentication exchange by sending the following message:
もしGSS_Init_sec_context（）へのクライアントの呼び出しが設定されていないinteg_availフラグでGSS_S_COMPLETEを返すと、クライアントは次のメッセージを送信することにより、ユーザー認証交換を締結しなければなりません：
byte SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE
バイトSSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE
This message MUST be sent only if GSS_Init_sec_context() returned GSS_S_COMPLETE. If a token is also returned, then the SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one.
もしGSS_Init_sec_context（）はGSS_S_COMPLETEを返された場合にのみ、このメッセージが送られなければなりません。トークンも返される場合、SSH_MSG_USERAUTH_GSSAPI_TOKENメッセージはこの前に送らなければなりません。
If this message is received by the server before the GSS-API context is fully established, the server MUST fail the authentication.
GSS-APIコンテキストが完全に確立される前に、このメッセージは、サーバによって受信された場合、サーバーは認証が失敗しなければなりません。
If this message is received by the server when the negotiated GSS-API context supports per-message integrity protection, the server MUST fail the authentication.
交渉さGSS-APIのコンテキストはメッセージごとの完全性保護をサポートしている場合、このメッセージは、サーバによって受信された場合、サーバーは認証が失敗しなければなりません。
It is a site policy decision for the server whether or not to permit authentication using GSS-API mechanisms and/or contexts that do not support per-message integrity protection. The server MAY fail the otherwise valid gssapi-with-mic authentication if per-message integrity protection is not supported.
これは、メッセージごとの完全性保護をサポートしていないGSS-APIメカニズムおよび/またはコンテキストを使用して認証を許可するか否かのサーバー用のサイトポリシーの決定です。メッセージごとの完全性保護がサポートされていない場合、サーバーは、そうでない場合は、有効なGSSAPI-と-MIC認証を失敗することがあります。
As with all SSH authentication methods, successful completion is indicated by an SSH_MSG_USERAUTH_SUCCESS if no other authentication is required, or an SSH_MSG_USERAUTH_FAILURE with the partial success flag set if the server requires further authentication. This packet SHOULD be sent immediately following receipt of the SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE packet.
サーバはさらに認証が必要な場合、他の認証が必要とされない場合、すべてのSSH認証方法と同様に、正常終了をSSH_MSG_USERAUTH_SUCCESSで示され、または部分的な成功フラグがセットされたSSH_MSG_USERAUTH_FAILURE。このパケットはSSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETEパケットの受信直後に送ってください。
In the event that a GSS-API error occurs on the server during context establishment, the server MAY send the following message to inform the client of the details of the error before sending an SSH_MSG_USERAUTH_FAILURE message:
GSS-APIエラーがコンテキストが確立しているときに、サーバー上で発生するイベントでは、サーバーはSSH_MSG_USERAUTH_FAILUREメッセージを送信する前に、エラーの内容をクライアントに通知するために、次のメッセージを送信することができます。
byte SSH_MSG_USERAUTH_GSSAPI_ERROR
uint32 major_status
uint32 minor_status
string message
string language tag
The message text MUST be encoded in the UTF-8 encoding described in [UTF8]. Language tags are those described in [LANGTAG]. Note that the message text may contain multiple lines separated by carriage return-line feed (CRLF) sequences. Application developers should take this into account when displaying these messages.
メッセージテキストは、[UTF8]に記載のUTF8エンコーディングでエンコードされなければなりません。言語タグは、[LANGTAG]に記載されているものです。メッセージテキストはキャリッジリターンラインフィード（CRLF）配列によって分離された複数の行を含んでいてもよいことに留意されたいです。これらのメッセージを表示するときにアプリケーション開発者は、このことを考慮すべきです。
Clients receiving this message MAY log the error details and/or report them to the user. Any server sending this message MUST ignore any SSH_MSG_UNIMPLEMENTED sent by the client in response.
このメッセージを受信するクライアントは、エラーの詳細をログに記録および/またはユーザーにそれらを報告することがあります。このメッセージを送信し、任意のサーバが応答してクライアントから送信されたすべてのSSH_MSG_UNIMPLEMENTEDを無視しなければなりません。
In the event that, during context establishment, a client's call to GSS_Init_sec_context() or a server's call to GSS_Accept_sec_context() returns a token along with an error status, the resulting "error token" SHOULD be sent to the peer using the following message:
エラーステータスと共にトークンを返すコンテキストの確立、もしGSS_Init_sec_contextへのクライアントの呼び出し（）または場合gss_accept_sec_context（のサーバーの呼び出し）の間、イベントでは、得られた「エラートークン」は、次のメッセージを使用して、ピアに送信されるべきです。
byte SSH_MSG_USERAUTH_GSSAPI_ERRTOK
string error token
This message implies that the authentication is about to fail, and is defined to allow the error token to be communicated without losing synchronization.
このメッセージは、認証が失敗しようとしている、とエラー・トークンが同期を失うことなく伝えることができるようにするために定義されていることを意味します。
When a server sends this message, it MUST be followed by an SSH_MSG_USERAUTH_FAILURE message, which is to be interpreted as applying to the same authentication request. A client receiving this message SHOULD wait for the following SSH_MSG_USERAUTH_FAILURE message before beginning another authentication attempt.
サーバはこのメッセージを送信するとき、それは同じ認証要求に適用するものとして解釈されるべきであるSSH_MSG_USERAUTH_FAILUREメッセージが続かなければなりません。このメッセージを受信するクライアントは、別の認証の試行を開始する前に、次のSSH_MSG_USERAUTH_FAILUREメッセージを待つべき。
When a client sends this message, it MUST be followed by a new authentication request or by terminating the connection. A server receiving this message MUST NOT send an SSH_MSG_USERAUTH_FAILURE in reply, since such a message might otherwise be interpreted by a client as a response to the following authentication sequence.
クライアントは、このメッセージを送信すると、それは新しい認証リクエストによって、または接続を終了するなければなりません。そのようなメッセージは、そうでなければ、次の認証シーケンスへの応答としてクライアントによって解釈されるかもしれないので、このメッセージを受信したサーバは、応答でSSH_MSG_USERAUTH_FAILUREを送ってはいけません。
Any server sending this message MUST ignore any SSH_MSG_UNIMPLEMENTED sent by the client in response. If a server sends both this message and an SSH_MSG_USERAUTH_GSSAPI_ERROR message, the SSH_MSG_USERAUTH_GSSAPI_ERROR message MUST be sent first, to allow the client to store and/or display the error status before processing the error token.
このメッセージを送信し、任意のサーバが応答してクライアントから送信されたすべてのSSH_MSG_UNIMPLEMENTEDを無視しなければなりません。サーバは、このメッセージとSSH_MSG_USERAUTH_GSSAPI_ERRORメッセージの両方を送信した場合、SSH_MSG_USERAUTH_GSSAPI_ERRORメッセージは、クライアントが保存および/またはエラー・トークンを処理する前に、エラー状態を表示できるようにするために、最初に送らなければなりません。
This section describes a user authentication method building on the framework described in [SSH-USERAUTH]. This method performs user authentication by making use of an existing GSS-API context established during key exchange.
このセクションでは、[SSH-USERAUTH]に記載のフレームワーク上でユーザ認証方法の建物が記載されています。この方法は、鍵交換の間に確立され、既存のGSS-APIコンテキストを利用してユーザ認証を行います。
The authentication method name for this protocol is "gssapi-keyex".
このプロトコルのための認証方法名は「GSSAPI-keyex」です。
This method may be used only if the initial key exchange was performed using a GSS-API-based key exchange method defined in accordance with Section 2. The GSS-API context used with this method is always that established during an initial GSS-API-based key exchange. Any context established during key exchange for the purpose of rekeying MUST NOT be used with this method.
初期鍵交換がこの方法で使用される第2のGSS-APIコンテキストに従って定義GSS-APIベースの鍵交換法を用いて行った場合にのみ、この方法を使用することができる初期GSS-API-中に確立することを常にベースの鍵交換。再入力の目的のための鍵交換の間に確立され、任意のコンテキストは、この方法で使用してはいけません。
The server SHOULD include this user authentication method in the list of methods that can continue (in an SSH_MSG_USERAUTH_FAILURE) if the initial key exchange was performed using a GSS-API-based key exchange method and provides information about the user's identity that is useful to the server. It MUST NOT include this method if the initial key exchange was not performed using a GSS-API-based key exchange method defined in accordance with Section 2.
サーバーは、最初の鍵交換は、GSS-APIベースの鍵交換方式を使用して実行してに便利であるユーザの身元に関する情報を提供していた場合（SSH_MSG_USERAUTH_FAILUREで）続けることができる方法のリストで、このユーザの認証方法を含むべきですサーバ。最初の鍵交換は、第2節に従って定義されたGSS-APIベースの鍵交換方式を使用して行われなかった場合は、この方法を含んではいけません。
The client SHOULD attempt to use this method if it is advertised by the server, initial key exchange was performed using a GSS-API-based key exchange method, and this method has not already been tried. The client SHOULD NOT try this method more than once per session. It MUST NOT try this method if initial key exchange was not performed using a GSS-API-based key exchange method defined in accordance with Section 2.
クライアントは、それが、最初の鍵交換は、GSS-APIベースの鍵交換方式を用いて行ったが、この方法は、すでに試されていないサーバーによってアドバタイズされた場合は、この方法を使用しようとするべきです。クライアントは、セッションごとに1回よりも、この方法の詳細を試みるべきではありません。最初の鍵交換は、第2節に従って定義されたGSS-APIベースの鍵交換方式を使用して行われなかった場合は、この方法を試してはなりません。
If a server receives a request for this method when initial key exchange was not performed using a GSS-API-based key exchange method defined in accordance with Section 2, it MUST return SSH_MSG_USERAUTH_FAILURE.
サーバは最初の鍵交換は、第2節に従って定義されたGSS-APIベースの鍵交換方式を使用して行われていなかったこのメソッドのリクエストを受信した場合、それはSSH_MSG_USERAUTH_FAILUREを返さなければなりません。
This method is defined as a single message:
この方法は、単一のメッセージのように定義されます。
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service
string "gssapi-keyex"
string MIC
The contents of the MIC field are obtained by calling GSS_GetMIC over the following, using the GSS-API context that was established during initial key exchange:
MICフィールドの内容は、最初の鍵交換の間に確立されたGSS-APIコンテキストを使用して、以下の上GSS_GetMICを呼び出すことによって得られます。
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service
string "gssapi-keyex"
Upon receiving this message when initial key exchange was performed using a GSS-API-based key exchange method, the server uses GSS_VerifyMIC() to verify that the MIC received is valid. If the MIC is not valid, the user authentication fails, and the server MUST return SSH_MSG_USERAUTH_FAILURE.
初期鍵交換がGSS-APIベースの鍵交換法を用いて行ったこのメッセージを受信すると、サーバは、受信したMICが有効であることを確認するために（）GSS_VerifyMICを使用します。 MICが有効でない場合、ユーザー認証は失敗し、サーバがSSH_MSG_USERAUTH_FAILUREを返さなければなりません。
If the MIC is valid and the server is satisfied as to the user's credentials, it MAY return either SSH_MSG_USERAUTH_SUCCESS or SSH_MSG_USERAUTH_FAILURE with the partial success flag set, depending on whether additional authentications are needed.
MICが有効で、サーバーがユーザーの資格情報にとして成立している場合、それは追加の認証が必要とされているかどうかに応じて、部分的な成功フラグを設定してSSH_MSG_USERAUTH_SUCCESSまたはSSH_MSG_USERAUTH_FAILUREのいずれかを返すことがあります。
The "null" host key algorithm has no associated host key material and provides neither signature nor encryption algorithms. Thus, it can be used only with key exchange methods that do not require any public-key operations and do not require the use of host public key material. The key exchange methods described in Section 2 are examples of such methods.
「ヌル」のホスト鍵アルゴリズムには関連付けられているホストキー材料を持っていないし、どちらも署名も暗号化アルゴリズムを提供しています。このように、それだけで任意のパブリック・キー操作を必要とせず、ホスト公開鍵の材料の使用を必要としない鍵交換方法で使用することができます。セクション2で説明鍵交換方法は、このような方法の例です。
This algorithm is used when, as a matter of configuration, the host does not have or does not wish to use a public key. For example, it can be used when the administrator has decided as a matter of policy to require that all key exchanges be authenticated using Kerberos [KRB5], and thus the only permitted key exchange method is the GSS-API-authenticated Diffie-Hellman exchange described above, with Kerberos V5 as the underlying GSS-API mechanism. In such a configuration, the server implementation supports the "ssh-dss" key algorithm (as required by [SSH-TRANSPORT]), but could be prohibited by configuration from using it. In this situation, the server needs some key exchange algorithm to advertise; the "null" algorithm fills this purpose.
このアルゴリズムは、構成の問題として、ホストが持っていないか、公開鍵を使用したくない場合は、使用されています。例えば、管理者は、ポリシーの問題として決定したときに、すべての鍵交換はケルベロス[KRB5]を使用して認証されることを必要とするために使用することができ、したがってのみ鍵交換方式を許可GSS-API認証のDiffie-Hellman交換であります下層のGSS-API機構としてKerberos V5を用いて、上記。 （[SSH-TRANSPORT]によって要求されるように）このような構成では、サーバの実装は、「SSH-DSS」キーアルゴリズムをサポートし、それを使用してからコンフィギュレーションによって禁止することができます。このような状況では、サーバは、宣伝するためにいくつかの鍵交換アルゴリズムを必要とします。 「ヌル」アルゴリズムは、この目的を満たします。
Note that the use of the "null" algorithm in this way means that the server will not be able to interoperate with clients that do not support this algorithm. This is not a significant problem, since in the configuration described, it will also be unable to interoperate with implementations that do not support the GSS-API-authenticated key exchange and Kerberos.
このように「ヌル」アルゴリズムの使用は、サーバーがこのアルゴリズムをサポートしていないクライアントと相互運用することはできないことを意味することに注意してください。上記構成では、また、GSS-API認証鍵交換とKerberosをサポートしない実装と相互運用することができませんので、これは、重大な問題ではありません。
Any implementation supporting at least one key exchange method that conforms to Section 2 MUST also support the "null" host key algorithm. Servers MUST NOT advertise the "null" host key algorithm unless it is the only algorithm advertised.
第2節に準拠少なくとも一つの鍵交換方式をサポートしている任意の実装も鍵アルゴリズムをホスト「ヌル」をサポートしなければなりません。サーバは、それが宣伝のみのアルゴリズムでない限り、「ヌル」キーアルゴリズムをホスト宣伝してはなりません。
The following message numbers have been defined for use with GSS-API-based key exchange methods:
次のメッセージ番号は、GSS-APIベースの鍵交換方法で使用するために定義されています：
#define SSH_MSG_KEXGSS_INIT 30
#define SSH_MSG_KEXGSS_CONTINUE 31
#define SSH_MSG_KEXGSS_COMPLETE 32
#define SSH_MSG_KEXGSS_HOSTKEY 33
#define SSH_MSG_KEXGSS_ERROR 34
#define SSH_MSG_KEXGSS_GROUPREQ 40
#define SSH_MSG_KEXGSS_GROUP 41
The numbers 30-49 are specific to key exchange and may be redefined by other kex methods.
番号30から49は、鍵交換に固有のものであり、他のKEX方法で再定義することができます。
The following message numbers have been defined for use with the 'gssapi-with-mic' user authentication method:
次のメッセージ番号は、「GSSAPI-と-マイク」ユーザー認証方式を使用するために定義されています：
#define SSH_MSG_USERAUTH_GSSAPI_RESPONSE 60
#define SSH_MSG_USERAUTH_GSSAPI_TOKEN 61
#define SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE 63
#define SSH_MSG_USERAUTH_GSSAPI_ERROR 64
#define SSH_MSG_USERAUTH_GSSAPI_ERRTOK 65
#define SSH_MSG_USERAUTH_GSSAPI_MIC 66
The numbers 60-79 are specific to user authentication and may be redefined by other user auth methods. Note that in the method described in this document, message number 62 is unused.
数字60-79は、ユーザ認証に固有であり、他のユーザの認証方法によって再定義することができます。この文書に記載された方法で、メッセージ番号62が未使用であることに留意されたいです。
In order to establish a GSS-API security context, the SSH client needs to determine the appropriate targ_name to use in identifying the server when calling GSS_Init_sec_context(). For this purpose, the GSS-API mechanism-independent name form for host-based services is used, as described in Section 4.1 of [GSSAPI].
GSS-APIのセキュリティコンテキストを確立するためには、SSHクライアントは、（）もしGSS_Init_sec_contextを呼び出すときに、サーバーを識別するのに使用するために適切なtarg_nameを決定する必要があります。 [GSSAPI]のセクション4.1に記載されているように、この目的のために、ホストベースのサービスのためのGSSAPIメカニズムに依存しない名前の形式は、使用されます。
In particular, the targ_name to pass to GSS_Init_sec_context() is obtained by calling GSS_Import_name() with an input_name_type of GSS_C_NT_HOSTBASED_SERVICE, and an input_name_string consisting of the string "host@" concatenated with the hostname of the SSH server.
特に、もしGSS_Init_sec_context（に渡すtarg_name）はGSS_C_NT_HOSTBASED_SERVICEのinput_name_type、およびSSHサーバのホスト名と連結「@ホスト」の文字列からなるinput_name_stringとGSS_Import_name（）を呼び出すことによって得られます。
Because the GSS-API mechanism uses the targ_name to authenticate the server's identity, it is important that it be determined in a secure fashion. One common way to do this is to construct the targ_name from the hostname as typed by the user; unfortunately, because some GSS-API mechanisms do not canonicalize hostnames, it is likely that this technique will fail if the user has not typed a fully-qualified, canonical hostname. Thus, implementers may wish to use other methods, but should take care to ensure they are secure. For example, one should not rely on an unprotected DNS record to map a host alias to the primary name of a server, or an IP address to a hostname, since an attacker can modify the mapping and impersonate the server.
GSS-APIメカニズムは、サーバーのIDを認証するためにtarg_nameを使用するので、安全な方法で決定することが重要です。これを行うための一般的な方法の1つは、ユーザーが入力したとして、ホスト名からtarg_nameを構築することです。いくつかのGSS-APIメカニズムは、ホスト名を正規化していないので、残念ながら、ユーザーが、完全修飾、正規のホスト名を入力していない場合は、この手法が失敗する可能性があります。したがって、実装者は、他の方法を使用したいかもしれないが、彼らが安全であることを確認するために世話をする必要があります。例えば、1は、攻撃者がマッピングを変更し、サーバになりすますことができるので、ホスト名にサーバーのプライマリ名、またはIPアドレスにホストエイリアスをマップするために保護されていないDNSレコードに頼るべきではありません。
Implementations of mechanisms conforming to this document MUST NOT use the results of insecure DNS queries to construct the targ_name. Clients MAY make use of a mapping provided by local configuration or use other secure means to determine the targ_name to be used. If a client system is unable to securely determine which targ_name to use, then it SHOULD NOT use this mechanism.
この文書に準拠するメカニズムの実装はtarg_nameを構築するために、安全でないDNSクエリの結果を使用してはなりません。クライアントは、ローカルの構成によって提供されるマッピングを利用したり、使用するtarg_nameを決定するために、他の安全な手段を使用するかもしれません。クライアントシステムが安全に使用するtarg_name決定することができない場合、それは、このメカニズムを使用しないでください。
This document recommends that channel bindings SHOULD NOT be specified in the calls during context establishment. This document does not specify any standard data to be used as channel bindings, and the use of network addresses as channel bindings may break SSH in environments where it is most useful.
この文書では、チャネルバインディングは、コンテキストが確立しているときに呼び出しで指定してはならないことをお勧めします。この文書では、チャネルバインディングとして使用する任意の標準データを指定しないと、チャネルバインディングなどのネットワークアドレスの使用は、それが最も有用である環境でSSHを壊すことがあります。
The use of the Simple and Protected GSS-API Negotiation Mechanism [SPNEGO] in conjunction with the authentication and key exchange methods described in this document is both unnecessary and undesirable. As a result, mechanisms conforming to this document MUST NOT use SPNEGO as the underlying GSS-API mechanism.
この文書に記載された認証及び鍵交換方法と共にシンプルかつ保護GSS-APIネゴシエーションメカニズム[SPNEGO]の使用が不要と望ましくないの両方です。その結果、本文書に準拠したメカニズムは、基礎となるGSS-APIメカニズムとしてSPNEGOを使用してはなりません。
Since SSH performs its own negotiation of authentication and key exchange methods, the negotiation capability of SPNEGO alone does not provide any added benefit. In fact, as described below, it has the potential to result in the use of a weaker method than desired.
SSHは、認証・鍵交換方式の独自の交渉を行っているので、一人でSPNEGOのネゴシエーション機能は、任意の付加的な利点を提供していません。実際には、後述のように、所望のより弱い方法の使用につながる可能性があります。
Normally, SPNEGO provides the added benefit of protecting the GSS-API mechanism negotiation. It does this by having the server compute a MIC of the list of mechanisms proposed by the client, and then checking that value at the client. In the case of key exchange, this protection is not needed because the key exchange methods described here already perform an equivalent operation; namely, they generate a MIC of the SSH exchange hash, which is a hash of several items including the lists of key exchange mechanisms supported by both sides. In the case of user authentication, the protection is not needed because the negotiation occurs over a secure channel, and the host's identity has already been proved to the user.
通常、SPNEGOは、GSS-API機構のネゴシエーションを保護する追加の利点を提供します。これは、サーバがクライアントによって提案されたメカニズムのリストのMICを計算したし、クライアントにその値をチェックすることでこれを行います。ここで説明する鍵交換方法は、すでに同等の操作を行うため、鍵交換の場合には、この保護は必要ありません。すなわち、それらは、両側でサポートされている鍵交換メカニズムのリストを含むいくつかのアイテムのハッシュであるSSH交換ハッシュのMICを生成します。交渉が安全なチャネルを介して行われ、ホストのアイデンティティがすでにユーザーに証明されているため、ユーザ認証の場合には、保護が必要とされていません。
The use of SPNEGO combined with GSS-API mechanisms used without SPNEGO can lead to interoperability problems. For example, a client that supports key exchange using the Kerberos V5 GSS-API mechanism [KRB5-GSS] only underneath SPNEGO will not interoperate with a server that supports key exchange only using the Kerberos V5 GSS-API mechanism directly. As a result, allowing GSS-API mechanisms to be used both with and without SPNEGO is undesirable.
SPNEGOなしで使用GSS-APIメカニズムと組み合わせSPNEGOの使用は、相互運用性の問題につながることができます。たとえば、唯一のSPNEGOの下のKerberos V5 GSS-APIメカニズム[KRB5-GSS]を使用して鍵交換をサポートするクライアントは、唯一の直接のKerberos V5 GSS-APIメカニズムを使用して鍵交換をサポートするサーバーと相互運用しません。結果として、SPNEGOで及びなしの両方に使用するGSS-API機構を可能にすることは望ましくありません。
If a client's policy is to first prefer GSS-API-based key exchange method X, then non-GSS-API method Y, then GSS-API-based method Z, and if a server supports mechanisms Y and Z but not X, then an attempt to use SPNEGO to negotiate a GSS-API mechanism might result in the use of method Z when method Y would have been preferable. As a result, the use of SPNEGO could result in the subversion of the negotiation algorithm for key exchange methods as described in Section 7.1 of [SSH-TRANSPORT] and/or the negotiation algorithm for user authentication methods as described in [SSH-USERAUTH].
クライアントのポリシーでは、最初のGSS-APIベースの鍵交換方式のXを好むのであれば、その後、非GSS-APIメソッドY、その後、GSS-APIベースの方法のZ、およびサーバがメカニズムYとZではなくXをサポートしている場合、その後、方法Yが好ましいであったであろう場合にGSS-API機構をネゴシエートするSPNEGOを使用する試みは、方法Zの使用につながる可能性があります。 [SSH-USERAUTH]に記載されているように[SSH-TRANSPORT]および/またはユーザの認証方法のためのネゴシエーションアルゴリズムのセクション7.1で説明したようにその結果、SPNEGOの使用は、鍵交換方法のためのネゴシエーションアルゴリズムの転覆につながる可能性。
Consistent with Section 8 of [SSH-ARCH] and Section 4.6 of [SSH-NUMBERS], this document makes the following registrations:
[SSH-ARCH]と[SSH-NUMBERS]の4.6節の第8節と一致して、このドキュメントは以下の登録を行います
The family of SSH key exchange method names beginning with "gss-group1-sha1-" and not containing the at-sign ('@'), to name the key exchange methods defined in Section 2.3.
「GSS-GROUP1-sha1-」と含まないアットマーク（「@」）で始まるSSH鍵交換メソッド名の家族は、2.3節で定義された鍵交換方式に名前を付けます。
The family of SSH key exchange method names beginning with "gss-gex-sha1-" and not containing the at-sign ('@'), to name the key exchange methods defined in Section 2.5.
「GSS-GEX-sha1-」と含まないアットマーク（「@」）で始まるSSH鍵交換メソッド名の家族は、セクション2.5で定義された鍵交換方式に名前を付けます。
All other SSH key exchange method names beginning with "gss-" and not containing the at-sign ('@'), to be reserved for future key exchange methods defined in conformance with this document, as noted in Section 2.6.
他のすべてのSSH鍵交換メソッド名アットマーク（「@」）を含む「gss-」で始まるなく、2.6節で述べたように、本文書に準拠して定義された将来の鍵交換方式のために確保されます。
The SSH host public key algorithm name "null", to name the NULL host key algorithm defined in Section 5.
SSHは、第5節で定義されたNULLホストキーアルゴリズムに名前を付け、「ヌル」公開鍵アルゴリズム名をホストします。
The SSH user authentication method name "gssapi-with-mic", to name the GSS-API user authentication method defined in Section 3.
SSHユーザー認証メソッド名「GSSAPI-と-MIC」、第3節で定義されたGSS-APIのユーザ認証方式に名前を付けます。
The SSH user authentication method name "gssapi-keyex", to name the GSS-API user authentication method defined in Section 4.
SSHユーザー認証メソッド名「GSSAPI-keyex」、第4章で定義されたGSS-APIのユーザ認証方式に名前を付けます。
The SSH user authentication method name "gssapi" is to be reserved, in order to avoid conflicts with implementations supporting an earlier version of this specification.
SSHユーザ認証メソッド名「GSSAPI」は、本明細書の以前のバージョンをサポートする実装との衝突を回避するために、確保されるべきです。
The SSH user authentication method name "external-keyx" is to be reserved, in order to avoid conflicts with implementations supporting an earlier version of this specification.
SSHユーザ認証メソッド名「外部keyx」は、本明細書の以前のバージョンをサポートする実装との衝突を回避するために、確保されるべきです。
This document creates no new registries.
この文書は、新しいレジストリを作成しません。
This document describes authentication and key-exchange protocols. As such, security considerations are discussed throughout.
この文書では、認証と鍵交換プロトコルについて説明します。そのため、セキュリティ上の考慮事項は、全体で議論されています。
This protocol depends on the SSH protocol itself, the GSS-API, any underlying GSS-API mechanisms that are used, and any protocols on which such mechanisms might depend. Each of these components plays a part in the security of the resulting connection, and each will have its own security considerations.
このプロトコルはSSHプロトコル自体、GSS-API、使用される任意の下地GSS-API機構、及びそのような機構が依存かもしれない上の任意のプロトコルに依存します。これらの各コンポーネントは、その結果、接続のセキュリティにおける役割を果たし、それぞれが独自のセキュリティ上の考慮事項があります。
The key exchange method described in Section 2 depends on the underlying GSS-API mechanism to provide both mutual authentication and per-message integrity services. If either of these features is not supported by a particular GSS-API mechanism, or by a particular implementation of a GSS-API mechanism, then the key exchange is not secure and MUST fail.
第2節で説明した鍵交換方式は、相互認証とメッセージごとの整合性の両方のサービスを提供するために、基本的なGSS-APIメカニズムに依存します。これらの機能のいずれかが特定のGSS-APIメカニズムでサポートされている、またはGSS-API機構の特定の実装によってされていない場合、鍵交換が安全ではないと失敗しなければなりません。
In order for the "external-keyx" user authentication method to be used, it MUST have access to user authentication information obtained as a side-effect of the key exchange. If this information is unavailable, the authentication MUST fail.
使用する「外部keyx」ユーザ認証方法のためには、鍵交換の副作用として取得したユーザ認証情報にアクセスしなければなりません。この情報が利用できない場合、認証は失敗しなければなりません。
Revealing information about the reason for an authentication failure may be considered by some sites to be an unacceptable security risk for a production environment. However, having that information available can be invaluable for debugging purposes. Thus, it is RECOMMENDED that implementations provide a means for controlling, as a matter of policy, whether to send SSH_MSG_USERAUTH_GSSAPI_ERROR, SSH_MSG_USERAUTH_GSSAPI_ERRTOK, and SSH_MSG_KEXGSS_ERROR messages, and SSH_MSG_KEXGSS_CONTINUE messages containing a GSS-API error token.
認証失敗の理由についての情報を明らかにすることは、本番環境のための容認できないセキュリティ上のリスクであることをいくつかのサイトで考慮することができます。しかし、その情報が利用可能になることはデバッグ目的のために非常に貴重なことができます。したがって、実装はSSH_MSG_USERAUTH_GSSAPI_ERROR、SSH_MSG_USERAUTH_GSSAPI_ERRTOK、およびSSH_MSG_KEXGSS_ERRORメッセージ、およびGSS-APIエラー・トークンを含むSSH_MSG_KEXGSS_CONTINUEメッセージを送信するかどうか、政策の問題として、制御するための手段を提供することを推奨しています。
The authors would like to thank the following individuals for their invaluable assistance and contributions to this document:
作者は彼らの非常に貴重な支援と、この文書への貢献のために以下の個人に感謝したいと思います：
o Sam Hartman
サム・ハートマンについて
o Love Hornquist-Astrand
OラブHornquist-Astrand
o Joel N. Weber II
ジョエル・N.ウェーバーII
o Simon Wilkinson
お しもん うぃｌきんそん
o Nicolas Williams
Oニコラス・ウィリアムズ
Much of the text describing DH group exchange was borrowed from [GROUP-EXCHANGE], by Markus Friedl, Niels Provos, and William A. Simpson.
DH群交換を説明するテキストの多くはマーカスFriedlの、ニールス・プロボス、およびウィリアムA.シンプソンにより、[GROUP-EXCHANGE]から借用しました。
[ASN1] ISO/IEC, "ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690 (1997), ISO/ IEC 8825-1:1998, November 1998.
[ASN1] ISO / IEC、 "ASN.1エンコーディング規則：基本符号化規則（BER）、Canonicalの符号化規則（CER）と識別符号化規則（DER）の仕様"、ITU-T勧告X.690（1997）、ISO / IEC 8825から1：1998、1998年11月。
[GROUP-EXCHANGE] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4419, March 2006.
[GROUP-EXCHANGE] Friedlの、M.、プロボス氏、N.、およびW.シンプソン、 "セキュアシェル（SSH）トランスポート層プロトコルのためのDiffie-Hellmanのグループ交換"、RFC 4419、2006年3月。
[GSSAPI] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[GSSAPI]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート1"、RFC 2743、2000年1月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[LANGTAG] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[LANGTAG] Alvestrand、H.、 "言語識別のためのタグ"、BCP 47、RFC 3066、2001年1月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5] Rivest氏、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[SSH-ARCH] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[SSH-ARCH] Ylonenと、T.とC. Lonvick、 "セキュアシェル（SSH）プロトコルアーキテクチャ"、RFC 4251、2006年1月。
[SSH-CONNECT] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
[SSH-CONNECT] Ylonenと、T.とC. Lonvick、 "セキュアシェル（SSH）接続プロトコル"、RFC 4254、2006年1月。
[SSH-NUMBERS] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[SSH-NUMBERS]レーティネン、S.とC. Lonvick、 "セキュアシェル（SSH）プロトコル割り当て番号"、RFC 4250、2006年1月。
[SSH-TRANSPORT] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[SSH-TRANSPORT] Ylonenと、T.とC. Lonvick、 "セキュアシェル（SSH）トランスポート層プロトコル"、RFC 4253、2006年1月。
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[SSH-USERAUTH] Ylonenと、T.とC. Lonvick、 "セキュアシェル（SSH）認証プロトコル"、RFC 4252、2006年1月。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF8] Yergeau、F.、 "UTF8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[KRB5] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
【KRB5]ノイマン、C.、ゆう、T.、ハルトマン、S.、およびK.レイバーン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 4120、2005年7月。
[KRB5-GSS] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
[KRB5-GSS]朱、L.、Jaganathan、K.、およびS.ハートマン、 "Kerberosバージョン5の汎用セキュリティサービスアプリケーションプログラムインタフェース（GSS-API）メカニズム：バージョン2"、RFC 4121、2005年7月。
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[SASLPREP] Zeilenga、K.、：、RFC 4013、2005年2月 "SASLprepユーザ名とパスワードのためのstringprepプロフィール"。
[SPNEGO] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism", RFC 4178, October 2005.
[SPNEGO]朱、L.、リーチ、P.、Jaganathan、K.、およびW.インガーソル、 "単純で保護された一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）交渉メカニズム"、RFC 4178、2005年10月。
Authors' Addresses
著者のアドレス
Jeffrey Hutzelman Carnegie Mellon University 5000 Forbes Ave Pittsburgh, PA 15213 US
ジェフリーHutzelmanカーネギーメロン大学5000フォーブスアベニューピッツバーグ、PA 15213米国
Phone: +1 412 268 7225 EMail: jhutz+@cmu.edu URI: http://www.cs.cmu.edu/~jhutz/
電話：+1 412 268 7225 Eメール：jhutz+@cmu.edu URI：http://www.cs.cmu.edu/~jhutz/
Joseph Salowey Cisco Systems 2901 Third Avenue Seattle, WA 98121 US
ジョセフSaloweyシスコシステムズ2901 Third Avenueのシアトル、WA 98121米国
Phone: +1 206 256 3380 EMail: jsalowey@cisco.com
電話：+1 206 256 3380 Eメール：jsalowey@cisco.com
Joseph Galbraith Van Dyke Technologies, Inc. 4848 Tramway Ridge Dr. NE Suite 101 Albuquerque, NM 87111 US
ジョセフ・ガルブレイスヴァン・ダイク・テクノロジーズ株式会社4848路面電車リッジ博士NEスイート101アルバカーキ、NM 87111米国
EMail: galb@vandyke.com
メールアドレス：galb@vandyke.com
Von Welch University of Chicago & Argonne National Laboratory Distributed Systems Laboratory 701 E. Washington Urbana, IL 61801 US
シカゴ＆アルゴンヌ国立研究所のフォン・ウェルチ大学は、システム研究所701 E.ワシントンアーバナ、イリノイ州61801米国を分散します
EMail: welch@mcs.anl.gov
メールアドレス：welch@mcs.anl.gov
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。