[要約] RFC 4462は、SSHプロトコルのためのGSS-API認証と鍵交換のための汎用セキュリティサービスアプリケーションプログラムインターフェース（GSS-API）に関する仕様です。このRFCの目的は、SSHセッションのセキュリティを向上させるために、GSS-APIを使用して認証と鍵交換を行う方法を提供することです。
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
ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）セキュアシェル（SSH）プロトコルの認証とキーエクスチェンジ
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).
Copyright（c）The Internet Society（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 Protocol（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ユーザー認証方法と、GSS-APIを使用してDiffie-Hellmanキー交換を認証する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を使用して、安全なシェルプロトコルでキーエクスチェンジとユーザー認証を実行するために使用される方法について説明します。これを行うには、主要な交換方法のファミリー、2つのユーザー認証方法、および新しいホストキーアルゴリズムを定義します。これらの定義により、GSS-APIメカニズムを安全なシェルプロトコルで使用できます。
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プロトコルアーキテクチャ[SSH-ARCH]、輸送層プロトコル[SSH-Transport]、およびユーザー認証プロトコル[SSH-Userauth]を説明するドキュメントを読んだ後にのみ読み取る必要があります。このドキュメントは、参照またはさらなる説明なしに、アーキテクチャドキュメントの用語と表記を自由に使用します。
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接続プロトコル[SSH-Connect]を指します。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
このセクションでは、[SSH-Transport]のセクション8からのDiffie-Hellmanキー交換とGSS-APIを使用した相互認証を組み合わせた主要な交換方法のクラスを定義します。
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で説明されている「null」アルゴリズムを含むホストキーアルゴリズムとともに使用できます。
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（）を呼び出します。この呼び出しでは、クライアントは相互認証を実行するように要求するために、相互_REQ_FLAGを「TRUE」に設定する必要があります。また、INTEG_REQ_FLAGを「True」に設定して、このコンテキストの整合性保護をサポートすることを要求する必要があります。さらに、deleg_req_flagは、ユーザーが要求した場合、アクセス委任を要求するように「真」に設定される場合があります。キー交換プロセスはホストのみを認証するため、ANON_REQ_FLAGの設定はこのプロセスには重要ではありません。クライアントがセクション4で説明した「GSSAPI-KEYEX」ユーザー認証方法をサポートしていない場合、またはキー交換中に確立されたGSS-APIコンテキストと併せてそのメソッドを使用するつもりはない場合、ANON_REQ_FLAGは「True」に設定する必要があります。。それ以外の場合、クライアントがそのアイデンティティを隠したい場合、このフラグは真実に設定される場合があります。キー交換プロセスには、コンテキストが確立されると、単一のトークンのみの交換が含まれるため、GSS-APIコンテキストが再生されたトークンまたはアウトオブシーケンストークンの検出をサポートする必要はありません。したがって、Replay_det_req_flagとsequence_req_flagをこのプロセスに設定する必要はありません。これらのフラグは「false」に設定する必要があります。
* 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.
* 結果のMajor_StatusコードがGSS_S_COMPLETEであり、Mutual_Stateフラグが真でない場合、相互認証は確立されておらず、重要な交換が失敗する必要があります。
* 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であり、相互_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はSに送信され、GSS_INIT_SEC_CONTEXT（）に提供される新しいトークンで返信されます。
* 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」を受信した場合、またはまったく受け取っていない場合、キーエクスチェンジは失敗します。
* 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はCから受信したトークンを使用して、gss_accept_sec_context（）を呼び出します
* 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.
* 結果のMajor_StatusコードがGSS_S_COMPLETEであり、Mutual_Stateフラグが真でない場合、相互認証は確立されておらず、重要な交換が失敗する必要があります。
* 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であり、相互_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 = hash（v_c || v_s || i_c || i_s || k_s || e || f || k）を計算します。次に、GSS_GETMIC（）を呼び出して、HのGSS-APIメッセージ整合性コードを取得します。その後、Fとメッセージ整合性コード（MIC）をCに送信します。
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（）へのサーバーの最終呼び出しがクライアントに送信するためにゼロ以外の最終返信トークンを作成した場合にのみ実行されます。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 = hash（v_c || v_s || i_c || i_s || k_s || e || f || k）を計算します。次に、gss_verifymic（）を呼び出して、Sから送信されたマイクがHと一致することを確認します。マイクが正常に検証されていない場合、キー交換は失敗する必要があります。
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_s_completeまたはgss_s_continue_needed以外のmajor_statusを返している場合、または他のGSS-APIコールは、GSS_S_S_S_S_S_S_S_S_S_S_S_S_STATUSを返します。この場合、[ssh-stransport]の要求に応じて接続を終了する前に、エラー情報をピアに通信するためにいくつかのメカニズムが利用可能です。
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.
o サーバー上のGSS-APIエラー（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.
o GSS_ACCEPT_SEC_CONTEXT（）へのサーバーの呼び出しからGSS-APIエラーが返され、「エラートークン」も返された場合、キー交換が失敗し、「エラートークン」がクライアントにエラートークンを送信して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.
o GSS_INIT_SEC_CONTEXT（）へのクライアントの呼び出しからGSS-APIエラーが返され、「エラートークン」も返された場合、キー交換が失敗し、クライアントは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.
これは、次のメッセージで実装されています。交換ハッシュを計算するためのハッシュアルゴリズムは、メソッド名で定義され、ハッシュと呼ばれます。Diffie-Hellman Key Exchangeと基礎となる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
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)
BYTE SSH_MSG_KEXGSS_HOSTKEY STRING SERVERパブリックホストキーと証明書（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で説明されている「null」ホストキーアルゴリズムが使用されている場合、このメッセージを送信してはなりません。このメッセージが送信されると、このメッセージのサーバーパブリックホストキーおよび/または証明書は、使用中の公開キータイプで指定された形式で単一の文字列としてエンコードされます（[SSH-Transport]を参照してください。セクション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展開では、ホストキーは通常、頻繁に変化すると予想されており、多くの場合、クライアントにはまだ知られていないホストキーを検証するメカニズムはありません。その結果、すでに知られているホストによる新しいホストキーの使用は、通常、中間の攻撃の可能性の兆候と見なされ、クライアントはしばしば強い警告を提示したり、そのような場合に接続を中止したりします。
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.
したがって、GSS-APIベースのキーエクスチェンジの成功を条件として、すでに知られているホストの新しいキーがssh_kexgss_hostkeyメッセージを介して受信された場合、クライアントは強力な警告を発行したり、接続を中止したりしないでください。
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_S_CONTINUE_NEEDEDのMajor_Statusコードを返すたびに、次の返信をクライアントに送信します。
byte SSH_MSG_KEXGSS_CONTINUE string output_token (from GSS_Accept_sec_context())
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_INIT_SEC_CONTEXT（）がGSS_S_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())
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_s_continue_neededのmajoy_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())
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_INIT_SEC_CONTEXT（）がGSS_S_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
byte ssh_msg_kexgss_complete mpint f string per_msg_token（high 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のMajoy_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
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
byte ssh_msg_kexgss_error uint32 major_status uint32 minor_status文字列メッセージ文字列タグ
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]で説明されているUTF-8エンコードでエンコードする必要があります。言語タグは[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
文字列v_c、クライアントのバージョン文字列（cr、nl除外）文字列v_s、サーバーのバージョン文字列（cr、nl除外）文字列i_c、クライアントのssh_kexinit文字列i_sのペイロード、サーバーのssh_msg_kexinit文字列k_sのペイロード、ホストキーMPINT E、クライアントMPINT Fによって送信された交換値、サーバーMPINT Kによって送信された交換値、共有秘密
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.
この値はExchange Hashと呼ばれ、キーエクスチェンジの認証に使用されます。交換ハッシュは秘密にしておく必要があります。ssh_msg_kexgss_hostkeyメッセージがサーバーによって送信されないか、クライアントが受信していない場合、Exchangeハッシュを計算するときに空の文字列が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-Authised Diffie-Hellman Key Exchangeの変更について説明します。
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.
サーバーは、安全な素数と選択できる対応するジェネレーターのリストを保持します。これらは、[グループ交換]のセクション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は「min || n || max」をsに送り、最小限のグループサイズ、グループの優先サイズ、およびクライアントが受け入れるビットの最大グループサイズを示します。
2. S finds a group that best matches the client's request, and sends "p || g" to C.
2. Sは、クライアントのリクエストに最も一致するグループを見つけ、「p || g」をCに送信します。
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.
サーバーとクライアントは、kビットの弾性率の長さでグループをサポートする必要があります。ここで、1024 <= k <= 8192です。minとmaxの推奨値はそれぞれ1024と8192です。
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
BYTE SSH_MSG_KEXGSS_GROUPREQ UINT32 MIN、許容可能なグループUINT32 Nのビットの最小サイズ、グループのビットの優先サイズサーバーは、許容可能なグループのビットで最大サイズを送信する必要があります
The server responds with:
サーバーは次のとおりです。
byte SSH_MSG_KEXGSS_GROUP mpint p, safe prime mpint g, generator for subgroup in GF(p)
byte ssh_msg_kexgss_group mpint P、安全なプライムmpint G、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:
これに続いて、上記のセクション2.1で説明したメッセージ交換が続きますが、交換ハッシュ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 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
文字列v_c、クライアントのバージョン文字列（cr、nl除外）文字列v_s、サーバーのバージョン文字列（cr、nl除外）文字列i_c、クライアントのsshg_kexinit文字列i_sのペイロード、サーバーのssh_msg_kexinit文字列k_sのペイロード、ホストキーUINT32 MIN、許容可能なグループUINT32 Nのビットの最小サイズ、グループのビットの優先サイズは、サーバーがUINT32 Max、許容可能なグループMPINT Pのビットの最大サイズ、SAFE PRIME MPINT G、GFのサブグループの発電機を送信する必要があります（p）mpint e、クライアントmpint fによって送信された交換値、サーバーmpint kによって送信された交換値、共有秘密
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].
これらの各メソッドは、セクション2.1でSHA-1をハッシュとして説明したように、GSS-API-Authenticated Diffie-Hellmanキー交換を指定し、[SSH輸送]のセクション8.1で定義されているグループを指定します。各メソッドのメソッド名は、基礎となるGSSの[asn.1識別エンコードルール（der）のmd5ハッシュ[md5]のbase64エンコードとの文字列「gss-group1-sha1-」の連結です。-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].
これらの各メソッドは、セクション2.1でSHA-1をハッシュとして説明したように、GSS-API認証Diffie-Hellmanキー交換を指定し、[SSH輸送]のセクション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].
これらの各メソッドは、セクション2.2でSHA-1をハッシュとして説明したように、GSS-API-Authenticed Diffie-Hellman Key Exchangeを指定します。各メソッドのメソッド名は、基礎となる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-Authenticated Diffie-Hellman Key Exchange Algorithmを使用する方法については、異なるグループやハッシュ関数を使用する将来の方法を含みます。意図は、このような将来の方法の名前は、セクション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-with-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認証はコンテキストを維持する必要があります。認証は、クライアントが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 Exchangeで交換される資格情報に基づいてユーザー名が承認されることを確認します。ユーザー名が承認されていない場合、認証が失敗する必要があります。
The GSS-API authentication method is initiated when the client sends an SSH_MSG_USERAUTH_REQUEST:
GSS-API認証方法は、クライアントがSSH_MSG_USERAUTH_REQUESTを送信するときに開始されます。
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
BYTE SSH_MSG_USERAUTH_REQUEST文字列ユーザー名（ISO-10646 UTF-8エンコード）文字列サービス名（US-ASCII） "gssapi-with-mic"（us-asciiメソッド名）uint32 n[n]メカニズムoids
Mechanism OIDs are encoded according to the ASN.1 Distinguished Encoding Rules (DER), as described in [ASN1] and in Section 3.1 of
メカニズムOIDは、[ASN1]およびセクション3.1で説明されているように、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]。OIDSメカニズムは好みの順にリストする必要があり、サーバーはサポートするリストの最初のメカニズム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メカニズムを送信する必要があります。それ以外の場合、認証方法は順番に実行される場合があります。したがって、クライアントは最初に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の範囲外です。プライベートユーザーデータベースを維持するSSH実装は、[saslprep]で説明されているようにユーザー名を準備する必要があります。
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_requestに応答します。ssh_msg_userauth_failureのいずれもサポートされていない場合、または次のようにssh_msg_userauth_gssapi_responseを使用します。
byte SSH_MSG_USERAUTH_GSSAPI_RESPONSE string selected mechanism OID
BYTE SSH_MSG_USERAUTH_GSSAPI_RESPONSE STRING選択されたメカニズム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の1つでなければなりません。
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()
byte ssh_msg_userauth_gssapi_token文字列gss_init_sec_context（）または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を「true」に設定して、このコンテキストで整合性の整合性保護をサポートするよう要求する必要があります。さらに、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".
ユーザー認証プロセスは、その性質上、クライアントのみを認証するため、このプロセスには相互_req_flagの設定は必要ありません。このフラグは「false」に設定する必要があります。
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の設定は必要ありません。これらのフラグは「false」に設定する必要があります。
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.
追加のSSH_MSG_USERAUTH_GSSAPI_TOKENメッセージは、GSS-APIルーチンへの呼び出しがゼロ以外の長さのトークンを生成する場合にのみ送信されます。
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）を送信する場合にのみ、アクセスを許可することにより、改善されたセキュリティを取得することができます。この余分なレベルの保護により、クライアントに信頼性を確信させた「中間の」攻撃者は、実際のクライアントとサーバー間でユーザー認証メッセージを中継して、実際のサーバーにアクセスできます。この追加の保護は、gss_init_sec_context（）またはgss_accept_sec_context（）からの成功したreturnからのinteg_availフラグの設定によって示されるように、交渉されたGSS-APIコンテキストが統合ごとの整合性保護をサポートする場合に利用可能です。
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
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"
文字列セッション識別子バイトssh_msg_userauth_request文字列ユーザー名文字列 "gssapi-with-mic" "" 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（）へのクライアントの呼び出しがgss_s_completeをinteg_availフラグを設定しない場合、クライアントは次のメッセージを送信してユーザー認証交換を締めくくる必要があります。
byte SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE
byte 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
BYTE SSH_MSG_USERAUTH_GSSAPI_ERROR UINT32 MASION_STATUS UINT32 MINTER_STATUS文字列メッセージ文字列タグ
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]で説明されているUTF-8エンコードでエンコードする必要があります。言語タグは[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
BYTE SSH_MSG_USERAUTH_GSSAPI_ERRTOK文字列エラートークン
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ベースのキー交換方法を使用して初期キー交換が実行された場合にのみ使用できます。ベースのキー交換。再キーを再キーにする目的でキー交換中に確立されたコンテキストは、この方法で使用してはなりません。
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
BYTE SSH_MSG_USERAUTH_REQUEST文字列ユーザー名STING SRIVES SRIVE
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"
文字列セッション識別子byte ssh_msg_userauth_request文字列ユーザー名文字列service "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ベースのキー交換方法を使用して最初のキー交換が実行されたときにこのメッセージを受信すると、サーバーは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.
マイクが有効であり、ユーザーの資格情報に関してサーバーが満たされている場合、追加の認証が必要かどうかに応じて、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.
「null」ホストキーアルゴリズムには、関連するホストキーマテリアルがなく、署名または暗号化アルゴリズムも提供しません。したがって、パブリックキー操作を必要とせず、ホストの公開キー資料の使用を必要としない主要な交換方法でのみ使用できます。セクション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.
このアルゴリズムは、構成の問題として、ホストが公開キーを持っていない、または使用したくない場合に使用されます。たとえば、管理者がポリシーの問題として、すべての主要な交換をKerberos [KRB5]を使用して認証することを要求することを決定したときに使用できます。上記のGSS-APIメカニズムとしてKerberos V5を使用しています。このような構成では、サーバーの実装は「SSH-DSS」キーアルゴリズム（[SSH-Transport]で要求されている）をサポートしますが、構成により使用が禁止される可能性があります。この状況では、サーバーは宣伝するためにいくつかの重要な交換アルゴリズムが必要です。「null」アルゴリズムはこの目的を満たします。
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.
この方法で「null」アルゴリズムを使用すると、サーバーがこのアルゴリズムをサポートしていないクライアントと相互運用できないことを意味することに注意してください。これは重大な問題ではありません。これは、説明されている構成では、GSS-API-Authenticed Key Exchangeと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に準拠する少なくとも1つのキー交換方法をサポートする実装は、「null」ホストキーアルゴリズムもサポートする必要があります。サーバーは、宣伝されている唯一のアルゴリズムでない限り、「null」ホストキーアルゴリズムを宣伝してはなりません。
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-with-mic」ユーザー認証方法で使用するために定義されています。
#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で説明されているように、ホストベースのサービスのGSS-APIメカニズム非依存名フォームが使用されます。
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_mnt_name_typeのgss_mport_name（）を呼び出し、gss_c_nt_hostbased_serviceのinput_name_type、およびsshのホストサーバーのホストに包まれた "host@"の "host@"のinput_name_stringを構成することによって取得されます。
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メカニズムはTARG_NAMEを使用してサーバーのIDを認証するため、安全な方法で決定することが重要です。これを行う一般的な方法の1つは、ユーザーが入力したホスト名からtarg_nameを構築することです。残念ながら、一部のGSS-APIメカニズムはホスト名を正規化しないため、ユーザーが完全に資格のある標準ホスト名を入力していない場合、この手法は失敗する可能性があります。したがって、実装者は他の方法を使用したい場合がありますが、安全であることを確認するように注意する必要があります。たとえば、攻撃者がマッピングを変更してサーバーになりすましているため、保護されていないDNSレコードに頼ってホストエイリアスをサーバーの主な名前またはIPアドレスにマッピングしないでください。
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メカニズムの交渉を保護するという追加の利点を提供します。これは、クライアントが提案したメカニズムのリストのマイクをサーバーに計算し、クライアントでその値を確認することにより、これを行います。キー交換の場合、ここで説明する主要な交換方法はすでに同等の操作を実行しているため、この保護は必要ありません。つまり、SSH Exchangeハッシュのマイクを生成します。これは、両側がサポートする主要な交換メカニズムのリストを含むいくつかのアイテムのハッシュです。ユーザー認証の場合、安全なチャネルで交渉が行われ、ホストの身元がユーザーにすでに証明されているため、保護は必要ありません。
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と組み合わせたSPNEGOの使用は、SPNEGOなしで使用されるGSS-APIメカニズムを組み合わせたもので、相互運用性の問題につながる可能性があります。たとえば、Kerberos V5 GSS-APIメカニズム[KRB5-GSS]を使用したキー交換をサポートするクライアントは、SPNEGOの下でのみ、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ではなくメカニズムをサポートする場合、次にZではなくサポートする場合SPNEGOを使用してGSS-APIメカニズムを交渉しようとすると、メソッドYが望ましい場合にメソッドZを使用する可能性があります。その結果、SPNEGOの使用は、[SSH-Userauth]で説明されているユーザー認証方法のセクション7.1で説明されているように、主要な交換方法の交渉アルゴリズムの転換をもたらす可能性があります。。
Consistent with Section 8 of [SSH-ARCH] and Section 4.6 of [SSH-NUMBERS], this document makes the following registrations:
[SSH-ARCH]のセクション8および[SSH-Numbers]のセクション4.6と一致して、このドキュメントは次の登録を作成します。
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.
セクション2.3で定義されている主要な交換方法に名前を付けるために、「GSS-GROUP1-SHA1-」から始まり、AT-SIGN（ '@'）を含んでいないSSHキー交換メソッド名のファミリー名。
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.
セクション2.5で定義されている主要な交換方法に名前を付けるために、「GSS-GEX-SHA1-」から始まり、AT-SIGN（ '@'）を含みません。
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.
セクション2.6に記載されているように、このドキュメントに準拠して定義された将来のキー交換メソッドのために、「GSS」（ '@'）を含む「GSS」から始まる他のすべてのSSHキー交換メソッド名。
The SSH host public key algorithm name "null", to name the NULL host key algorithm defined in Section 5.
SSHホスト公開キーアルゴリズム名「Null」という名前。
The SSH user authentication method name "gssapi-with-mic", to name the GSS-API user authentication method defined in Section 3.
セクション3で定義されているGSS-APIユーザー認証メソッドに名前を付けるために、SSHユーザー認証方法「GSSAPI-With-Mic」という名前。
The SSH user authentication method name "gssapi-keyex", to name the GSS-API user authentication method defined in Section 4.
セクション4で定義されているGSS-APIユーザー認証方法に名前を付けるために、SSHユーザー認証方法「GSSAPI-KEYEX」という名前。
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ユーザー認証メソッド名「external-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メッセージ、SSH_MSG_KEXGSGSGS_CONTINUE CONTS AP AP APTINUEメッセージを含むSSH_KEXGSS_ERRORメッセージを送信するかどうか、ポリシーの問題として制御する手段を提供することをお勧めします。
The authors would like to thank the following individuals for their invaluable assistance and contributions to this document:
著者は、この文書への貴重な支援と貢献について、次の個人に感謝したいと思います。
o Sam Hartman
o サム・ハートマン
o Love Hornquist-Astrand
o Hornquist-Astrandが大好きです
o Joel N. Weber II
o ジョエルN.ウェーバーII
o Simon Wilkinson
o サイモン・ウィルキンソン
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グループの交換を説明するテキストの多くは、Markus Friedl、Niels Provos、およびWilliam A. Simpsonによって[グループエクスチェンジ]から借用されました。
[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）、標準エンコードルール（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.、Provos、N。、およびW. Simpson、「Secure Shell（SSH）輸送層プロトコルのDiffie-Hellman Group Exchange」、RFC 4419、2006年3月。
[GSSAPI] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[GSSAPI] Linn、J。、「Generic Security Service Application Program Interfaceバージョン2、Update 1」、RFC 2743、2000年1月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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。、「The MD5 Message-Digest Algorithm」、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] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、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、「The Secure Shell（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、「The Secure Shell（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] Lehtinen、S。およびC. Lonvick、「Secure Shell（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、「The Secure Shell（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、「The Secure Shell（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。、「UTF-8、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] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network認証サービス（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] Zhu、L.、Jaganathan、K。、およびS. Hartman、「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。、「Saslprep：ユーザー名とパスワードのStringPrepプロファイル」、RFC 4013、2005年2月。
[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] Zhu、L.、Leach、P.、Jaganathan、K。、およびW. Ingersoll、「シンプルで保護されたジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）交渉メカニズム」、RFC 4178、2005年10月。
Authors' Addresses
著者のアドレス
Jeffrey Hutzelman Carnegie Mellon University 5000 Forbes Ave Pittsburgh, PA 15213 US
ジェフリー・ハッツェルマンカーネギー・メロン大学5000フォーブスアベニューピッツバーグ、ペンシルバニア州15213米国
Phone: +1 412 268 7225
EMail: jhutz+@cmu.edu
URI: http://www.cs.cmu.edu/~jhutz/
Joseph Salowey Cisco Systems 2901 Third Avenue Seattle, WA 98121 US
ジョセフ・サロウィー・シスコ・システム2901サード・アベニュー・シアトル、ワシントン州98121米国
Phone: +1 206 256 3380
EMail: jsalowey@cisco.com
Joseph Galbraith Van Dyke Technologies, Inc. 4848 Tramway Ridge Dr. NE Suite 101 Albuquerque, NM 87111 US
Joseph Galbraith Van Dyke Technologies、Inc。4848 Tramway Ridge Dr. NE Suite 101 Albuquerque、NM 87111 US
EMail: 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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。