Network Working Group L. Zhu
Request for Comments: 4178 P. Leach
Obsoletes: 2478 K. Jaganathan
Category: Standards Track Microsoft Corporation
W. Ingersoll
Sun Microsystems
October 2005
The Simple and Protected
Generic Security Service Application Program Interface (GSS-API)
Negotiation Mechanism
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 (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API), which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. If per-message integrity services are available on the established mechanism context, then the negotiation is protected against an attacker that forces the selection of a mechanism not desired by the peers.
この文書は、2743 GSS-APIピアがセキュリティメカニズムの共通セットから選択するには、この交渉メカニズムを使用することができRFCに記述されている一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）、交渉メカニズムを指定します。メッセージごとの整合性サービスが確立メカニズムのコンテキストで使用可能な場合、交渉はピアが望まないメカニズムの選択を強制する攻撃から保護されています。
This mechanism replaces RFC 2478 in order to fix defects in that specification and to describe how to inter-operate with implementations of that specification that are commonly deployed on the Internet.
このメカニズムは、その仕様の欠陥を修正すると、一般的にインターネット上で展開されている仕様の実装と相互運用する方法を説明するために、RFC 2478を置き換えます。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Negotiation Protocol ............................................3
3.1. Negotiation Description ....................................4
3.2. Negotiation Procedure ......................................5
4. Token Definitions ...............................................7
4.1. Mechanism Types ............................................7
4.2. Negotiation Tokens .........................................7
4.2.1. negTokenInit ........................................8
4.2.2. negTokenResp ........................................9
5. Processing of mechListMIC ......................................10
6. Extensibility ..................................................13
7. Security Considerations ........................................13
8. Acknowledgments ................................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
Appendix A. SPNEGO ASN.1 Module ..................................16
Appendix B. GSS-API Negotiation Support API ......................17
B.1. GSS_Set_neg_mechs Call ...................................17
B.2. GSS_Get_neg_mechs Call ...................................18
Appendix C. Changes since RFC 2478 ...............................18
Appendix D. mechListMIC Computation Example ......................20
The GSS-API [RFC2743] provides a generic interface that can be layered atop different security mechanisms such that, if communicating peers acquire GSS-API credentials for the same security mechanism, then a security context may be established between them (subject to policy). However, GSS-API does not prescribe the method by which GSS-API peers can establish whether they have a common security mechanism.
GSS-API [RFC2743]は通信ピアが同じセキュリティ・メカニズムのGSS-API資格を取得した場合、セキュリティコンテキストは、それら（ポリシーの対象）との間で確立することができるよう、ことが異なるセキュリティメカニズムの上に積層することができる汎用的なインタフェースを提供します。ただし、GSS-APIは、GSS-APIピアは、彼らが共通のセキュリティ・メカニズムを持っているかどうかを確立することができる方法を規定していません。
The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism defined here is a pseudo security mechanism that enables GSS-API peers to determine in-band whether their credentials support a common set of one or more GSS-API security mechanisms; if so, it invokes the normal security context establishment for a selected common security mechanism. This is most useful for applications that depend on GSS-API implementations and share multiple mechanisms between the peers.
ここで定義されたシンプルで保護されたGSS-APIネゴシエーション（SPNEGO）機構は、資格情報は、1つまたは複数のGSS-APIのセキュリティメカニズムの共通セットをサポートするかどうかをインバンドを決定するためにGSS-APIピアを可能にする擬似セキュリティメカニズムです。もしそうなら、それは選択された共通のセキュリティメカニズムのための通常のセキュリティコンテキストの確立を起動します。これは、GSS-APIの実装に依存し、ピア間の複数のメカニズムを共有するアプリケーションのために最も有用です。
The SPNEGO mechanism negotiation is based on the following model: the initiator proposes a list of security mechanism(s), in decreasing preference order (favorite choice first), the acceptor (also known as the target) either accepts the initiator's preferred security mechanism (the first in the list) or chooses one of the available mechanisms from the offered list; if neither is acceptable, the acceptor rejects the proposed value(s). The target then informs the initiator of its choice.
SPNEGO機構交渉は以下のモデルに基づいています：イニシエータは、セキュリティ・メカニズム（複数可）のリストを提案し、優先順位（最初のお気に入りの選択肢）を小さくして、（もターゲットとして知られている）受容体は、（イニシエータの優先セキュリティメカニズムを受け入れるのいずれかリストの最初）または提供リストから利用可能なメカニズムのいずれかを選択します。いずれも許容可能である場合、アクセプターは、提案された値（複数可）を拒否する。ターゲットは、その選択肢のイニシエータに通知します。
Once a common security mechanism is chosen, mechanism-specific options MAY be negotiated as part of the selected mechanism's context establishment. These negotiations (if any) are internal to the mechanism and opaque to the SPNEGO protocol. As such, they are outside the scope of this document.
共通のセキュリティメカニズムが選択されると、機構固有のオプションが選択された機構のコンテキスト確立の一部として交渉されるかもしれません。これらの交渉（もしあれば）は、機構の内部とSPNEGOプロトコルに不透明です。そのため、彼らはこの文書の範囲外です。
If per-message integrity services [RFC2743] are available on the established mechanism security context, then the negotiation is protected to ensure that the mechanism list has not been modified. In cases where an attacker could have materially influenced the negotiation, peers exchange message integrity code (MIC) tokens to confirm that the mechanism list has not been modified. If no action of an attacker could have materially modified the outcome of the negotiation, the exchange of MIC tokens is optional (see Section 5). Allowing MIC tokens to be optional in this case provides interoperability with existing implementations while still protecting the negotiation. This interoperability comes at the cost of increased complexity.
メッセージごとの整合性サービス[RFC2743]は確立メカニズムのセキュリティコンテキストで利用可能であるならば、交渉は機構のリストが変更されていないことを確認するために保護されています。攻撃者は実質交渉に影響を与えた可能性のケースでは、ピア交換メッセージ整合性コード（MIC）は、メカニズムのリストが変更されていないことを確認するためのトークン。攻撃者のアクションが著しく交渉の結果を変更していない可能性がある場合、MICトークンの交換はオプションである（第5章を参照してください）。依然としてネゴシエーションを保護しながらMICトークンが、この場合に任意することを可能にする既存の実装との相互運用性を提供します。この相互運用性を高め、複雑のコストがかかります。
SPNEGO relies on the concepts developed in the GSS-API specification [RFC2743]. The negotiation data is encapsulated in context-level tokens. Therefore, callers of the GSS-API do not need to be aware of the existence of the negotiation tokens, but only of the new pseudo-security mechanism. A failure in the negotiation phase causes a major status code to be returned: GSS_S_BAD_MECH.
SPNEGOは、GSS-API仕様[RFC2743]で開発された概念に依存しています。ネゴシエーションデータは、コンテキストレベルトークンにカプセル化されます。したがって、GSS-APIの呼び出し側は、交渉トークンの存在が、唯一の新しい擬似セキュリティメカニズムを意識する必要はありません。 GSS_S_BAD_MECH：ネゴシエーションフェーズでの失敗が返される主要なステータスコードの原因となります。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
When the established mechanism context provides integrity protection, the mechanism negotiation can be protected. When acquiring negotiated security mechanism tokens, per-message integrity services are always requested by the SPNEGO mechanism.
確立メカニズムコンテキストが完全性保護を提供する場合、機構のネゴシエーションを保護することができます。交渉されたセキュリティ・メカニズムトークンを取得する場合、メッセージごとの完全性サービスは常にSPNEGOメカニズムにより要求されます。
When the established mechanism context supports per-message integrity services, SPNEGO guarantees that the selected mechanism is mutually preferred.
確立メカニズムのコンテキストはメッセージごとの整合性サービスをサポートしている場合、SPNEGOが選択された機構が相互に好適であることが保証されます。
This section describes the negotiation process of this protocol.
このセクションでは、このプロトコルのネゴシエーションプロセスを説明します。
The first negotiation token sent by the initiator contains an ordered list of mechanisms in decreasing preference order (favorite mechanism first), and optionally the initial mechanism token for the preferred mechanism of the initiator (i.e., the first in the list). (Note that the list MUST NOT contain this SPNEGO mechanism itself or any mechanism for which the client does not have appropriate credentials.)
イニシエータによって送信された最初のネゴシエーショントークンは、優先順位（第一お気に入り機構）を低減するのにメカニズムの順序付きリストを含み、開始剤（すなわち、リストの最初）の好適な機構の初期メカニズムトークンを任意。 （リストは、このSPNEGOメカニズム自体またはクライアントが適切な資格情報を持っていないための任意の機構を含んではならないことに注意してください。）
The target then processes the token from the initiator. This will result in one of four possible states (as defined in Section 4.2.2) being returned in the reply message: accept-completed, accept-incomplete, reject, or request-mic. A reject state will terminate the negotiation; an accept-completed state indicates that the initiator-selected mechanism was acceptable to the target, and that the security mechanism token embedded in the first negotiation message was sufficient to complete the authentication; an accept-incomplete state indicates that further message exchange is needed but the MIC token exchange (as described in Section 5) is OPTIONAL; a request-mic state (this state can only be present in the first reply message from the target) indicates that the MIC token exchange is REQUIRED if per-message integrity services are available.
ターゲットは、イニシエータからのトークンを処理します。完了を受け付け、受け付け、不完全、拒否、または要求MIC：これは、応答メッセージで返される（セクション4.2.2で定義されるように）4つの可能な状態のいずれかをもたらすであろう。 A交渉を終了する状態を拒否する。受け入れ完了状態は、イニシエータ選択機構がターゲットに受け入れた、最初のネゴシエーションメッセージに埋め込まれたセキュリティメカニズムトークンが認証を完了するのに十分であったことをことを示しています。受け入れ、不完全な状態は、さらにメッセージ交換が必要であることを示しているが、MICトークン交換（セクション5に記載されているように）は、オプションです。リクエストマイク状態（この状態は、ターゲットのみからの最初の応答メッセージに存在することができる）メッセージごとの完全性サービスが利用可能な場合MICトークン交換が必要であることを示しています。
Unless the preference order is specified by the application, the policy by which the target chooses a mechanism is an implementation-specific, local matter. In the absence of an application-specified preference order or other policy, the target SHALL choose the first mechanism in the initiator proposed list for which it has valid credentials.
優先順位は、アプリケーションによって指定されていない限り、ターゲット機構を選択したことにより、ポリシーが実装固有の、ローカルの問題です。アプリケーション指定の優先順位または他のポリシーがない場合、ターゲットは、それが有効な認証情報を持っているイニシエータ提案リスト内の最初の機構を選択SHALL。
In case of a successful negotiation, the security mechanism in the first reply message represents the value suitable for the target that was chosen from the list offered by the initiator.
成功した交渉の場合には、最初の応答メッセージのセキュリティメカニズムは、イニシエータによって提供されるリストから選択された目標に適した値を表します。
In case of an unsuccessful negotiation, the reject state is returned, and the generation of a context-level negotiation token is OPTIONAL.
失敗ネゴシエーションの場合には、拒否状態が返され、コンテキスト・レベルのネゴシエーショントークンの生成は任意です。
Once a mechanism has been selected, context establishment tokens specific to the selected mechanism are carried within the negotiation tokens.
機構が選択されると、選択された機構に特有のコンテキスト確立トークンはネゴシエーショントークン内に運ばれます。
Lastly, MIC tokens may be exchanged to ensure the authenticity of the mechanism list received by the target.
最後に、MICトークンは、ターゲットによって受信された機構リストの真正性を保証するために交換されてもよいです。
To avoid conflicts with the use of MIC tokens by SPNEGO, partially-established contexts MUST NOT be used for per-message calls. To guarantee this, the prot_ready_state [RFC2743] MUST be set to false on return from GSS_Init_sec_context() and GSS_Accept_sec_context(), even if the underlying mechanism returned true.
SPNEGOによってMICトークンの使用との競合を避けるために、部分的に確立されたコンテキストはメッセージごとのコールのために使用してはいけません。これを保証するために、のprot_ready_state [RFC2743]は根底にあるメカニズムはtrueを返した場合でも、もしGSS_Init_sec_context（）とのgss_accept_sec_context（）からの戻りにはfalseに設定しなければなりません。
Note that in order to avoid an extra round trip, the first context establishment token of the initiator's preferred mechanism SHOULD be embedded in the initial negotiation message (as defined in Section 4.2). (This mechanism token is referred to as the optimistic mechanism token in this document.) In addition, using the optimistic mechanism token allows the initiator to recover from non-fatal errors encountered when trying to produce the first mechanism token before a mechanism can be selected. In cases where the initiator's preferred mechanism is not likely to be selected by the acceptor because of the significant cost of its generation, implementations MAY omit the optimistic mechanism token.
（セクション4.2で定義されるように）、余分なラウンドトリップを回避するために、開始剤の好適な機構の第1コンテキスト確立トークンが最初のネゴシエーションメッセージに埋め込まれるべきであることに注意してください。 （この機構のトークンは、この文書に記載されている楽観的機構トークンと呼ばれる。）また、楽観的機構のトークンを使用する機構を選択することができる前に、イニシエータは、第1機構トークンを生成しようとするときに遭遇する非致命的なエラーから回復することを可能にします。イニシエータの優先メカニズムは、その世代の大幅なコストのアクセプタによって選択される可能性が低い場合には、実装は楽観的メカニズムトークンを省略することができます。
The basic form of the procedure assumes that per-message integrity services are available on the established mechanism context, and it is summarized as follows:
手順の基本的な形は、メッセージごとの整合性サービスが確立メカニズムのコンテキストで利用可能であることを前提とし、以下のように要約されます。
a) The GSS-API initiator invokes GSS_Init_sec_context() as normal, but requests that SPNEGO be used. SPNEGO can either be explicitly requested or accepted as the default mechanism.
A）GSS-API開始剤を使用することがSPNEGO通常、しかし要求としてもしGSS_Init_sec_context（）を呼び出します。 SPNEGOは、明示的に要求するか、デフォルトのメカニズムとして受け入れることができます。
b) The initiator GSS-API implementation generates a negotiation token containing a list of one or more security mechanisms that are available based on the credentials used for this context establishment, and optionally on the initial mechanism token for the first mechanism in the list.
B）イニシエータGSS-APIの実装は、このコンテキストの確立のために、そして必要に応じて、リスト内の最初の機構の初期メカニズムトークンに使用される資格情報に基づいて利用可能な1つのまたは複数のセキュリティメカニズムのリストを含むネゴシエーショントークンを生成します。
c) The GSS-API initiator application sends the token to the target application. The GSS-API target application passes the token by invoking GSS_Accept_sec_context(). The acceptor will do one of the following:
C）GSS-APIのイニシエータ・アプリケーションは、ターゲットアプリケーションにトークンを送信します。 GSS-APIのターゲットアプリケーションが場合gss_accept_sec_contextを呼び出すことによって、トークンを渡します（）。アクセプターは、次のいずれかを実行します。
I) If none of the proposed mechanisms are acceptable, the
negotiation SHALL be terminated. GSS_Accept_sec_context
indicates GSS_S_BAD_MECH. The acceptor MAY output a
negotiation token containing a reject state.
II) If either the initiator's preferred mechanism is not accepted by the target or this mechanism is accepted but is not the acceptor's most preferred mechanism (i.e., the MIC token exchange as described in Section 5 is required),
II）のいずれかの開始剤の好ましい機構はターゲットによって受け入れられていないか、この機構が受け入れられるが、アクセプターの最も好適な機構ではない場合（つまりは、セクション5で説明したようにMICトークン交換が必要です）、
GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED.
The acceptor MUST output a negotiation token containing a
request-mic state.
III) Otherwise, if at least one additional negotiation token from the initiator is needed to establish this context, GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and outputs a negotiation token containing an accept-incomplete state.
イニシエータからの少なくとも一つの追加のネゴシエーショントークンがこのコンテキストを確立するために必要とされる場合III）そうでなければ、場合gss_accept_sec_context（）はGSS_S_CONTINUE_NEEDEDを示し、受け入れ、不完全な状態を含むネゴシエーショントークンを出力します。
IV) Otherwise, no additional negotiation token from the initiator is needed to establish this context, GSS_Accept_sec_context() indicates GSS_S_COMPLETE and outputs a negotiation token containing an accept_complete state.
IV）そうでない場合は、イニシエータからの追加のネゴシエーショントークンがこのコンテキストを確立するために必要とされない、場合gss_accept_sec_context（）はGSS_S_COMPLETEを示し、accept_complete状態を含むネゴシエーショントークンを出力します。
If the initiator's preferred mechanism is accepted, and an optimistic mechanism token was included, this mechanism token MUST be passed to the selected mechanism by invoking GSS_Accept_sec_context(). If a response mechanism token is returned, it MUST be included in the response negotiation token. Otherwise, the target will not generate a response mechanism token in the first reply.
イニシエータの好ましい機構が受け付けられ、そして楽観的機構トークンが含まれていた場合、このメカニズムトークンはgss_accept_sec_context（）をを呼び出すことによって、選択された機構に渡さなければなりません。応答メカニズムトークンが返された場合、それは応答交渉トークンに含まれなければなりません。それ以外の場合は、ターゲットは、最初の応答で応答メカニズムトークンを生成しません。
d) The GSS-API target application returns the negotiation token to the initiator application. The GSS-API initiator application passes the token by invoking GSS_Init_sec_context(). The security context initialization is then continued according to the standard GSS-API conventions for the selected mechanism, where the tokens of the selected mechanism are encapsulated in negotiation messages (see Section 4) until GSS_S_COMPLETE is returned for both the initiator and the target by the selected security mechanism.
D）GSS-APIのターゲットアプリケーションは、イニシエータ・アプリケーションに交渉トークンを返します。 GSS-APIのイニシエータアプリケーション）が（もしGSS_Init_sec_contextを呼び出すことによって、トークンを渡します。セキュリティ・コンテキストの初期化は、その後、GSS_S_COMPLETEがイニシエータによってターゲットの両方のために戻されるまで、選択された機構のトークンが（セクション4を参照）交渉メッセージ内にカプセル化された選択機構のための標準的なGSS-APIの規則に従って続行されます選択されたセキュリティメカニズム。
e) MIC tokens are then either skipped or exchanged according to Section 5.
e）のMICトークンは、その後されているかは、第5節によると、スキップ・交換します。
Note that the *_req_flag input parameters for context establishment are relative to the selected mechanism, as are the *_state output parameters. That is, these parameters are not applicable to the negotiation process per se.
* _state出力パラメータがそうであるようにコンテキストを確立するため* _req_flag入力パラメータは、選択された機構に対するものであることに留意されたいです。つまり、これらのパラメータは、交渉プロセス自体には適用されません。
On receipt of a negotiation token on the target side, a GSS-API implementation that does not support negotiation would indicate the GSS_S_BAD_MECH status as though a particular basic security mechanism had been requested and was not supported.
特定の基本的なセキュリティメカニズムが要求されていたし、サポートされていなかったかのように、ターゲット側の交渉トークンを受信すると、ネゴシエーションをサポートしていないGSS-APIの実装はGSS_S_BAD_MECHの状態を示すことになります。
When a GSS-API credential is acquired for the SPNEGO mechanism, the implementation SHOULD produce a credential element for the SPNEGO mechanism that internally contains GSS-API credential elements for all mechanisms for which the principal has credentials available, except for any mechanisms that are not to be negotiated, per implementation-, site-, or application-specific policy. See Appendix B for interfaces for expressing application policy.
GSS-API資格をSPNEGO機構のために取得した場合、実装は、内部主要ではない任意の機構を除いて利用可能な資格を有しているすべてのメカニズムのGSS-API資格要素を含むSPNEGO機構の資格要素を生成しなければなりません実装に、部位特異的、またはアプリケーション固有のポリシーごとに、交渉することにします。アプリケーションポリシーを表現するためのインターフェースについては、付録Bを参照してください。
The type definitions in this section assume an ASN.1 module definition of the following form:
このセクションのタイプの定義は、次の形式のASN.1モジュールの定義を前提としています。
SPNEGOASNOneSpec {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanism(5) snego (2) modules(4) spec2(2)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- rest of definitions here
- ここでの定義の残りの部分
END
終わり
This specifies that the tagging context for the module will be explicit and non-automatic.
これは、モジュールのタグ付けコンテキストは、明示的および非自動になることを指定します。
The encoding of the SPNEGO protocol messages shall obey the Distinguished Encoding Rules (DER) of ASN.1, as described in [X690].
[X690]に記載されているようにSPNEGOプロトコルメッセージの符号化は、ASN.1の識別符号化規則（DER）に従わなければなりません。
In this negotiation model, each OID represents one GSS-API mechanism or one variant (see Section 6) of it, according to [RFC2743].
このネゴシエーションモデルでは、各OIDは、[RFC2743]によれば、それのGSS-API機構または1つの変異体（セクション6）を表します。
MechType ::= OBJECT IDENTIFIER
-- OID represents each security mechanism as suggested by
-- [RFC2743]
MechTypeList ::= SEQUENCE OF MechType
The syntax of the initial negotiation tokens follows the initialContextToken syntax defined in Section 3.1 of [RFC2743]. The SPNEGO pseudo mechanism is identified by the Object Identifier iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2). Subsequent tokens MUST NOT be encapsulated in this GSS-API generic token framing.
最初のネゴシエーショントークンの構文は、[RFC2743]のセクション3.1で定義されたinitialContextTokenの構文に従います。 SPNEGO擬似機構は、オブジェクト識別子iso.org.dod.internet.security.mechanism.snego（1.3.6.1.5.5.2）によって識別されます。後続のトークンは、このGSS-APIの一般的なトークンのフレーミングにカプセル化してはなりません。
This section specifies the syntax of the inner token for the initial message and the syntax of subsequent context establishment tokens.
このセクションでは、最初のメッセージの内のトークンとそれに続くコンテキスト確立トークンの構文の構文を指定します。
NegotiationToken ::= CHOICE {
negTokenInit [0] NegTokenInit,
negTokenResp [1] NegTokenResp
}
NegTokenInit ::= SEQUENCE {
mechTypes [0] MechTypeList,
reqFlags [1] ContextFlags OPTIONAL,
-- inherited from RFC 2478 for backward compatibility,
-- RECOMMENDED to be left out
mechToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL,
...
}
ContextFlags ::= BIT STRING {
delegFlag (0),
mutualFlag (1),
replayFlag (2),
sequenceFlag (3),
anonFlag (4),
confFlag (5),
integFlag (6)
} (SIZE (32))
This is the syntax for the inner token of the initial negotiation message.
これは最初のネゴシエーションメッセージの内部トークンの構文です。
mechTypes
mechTypos
This field contains one or more security mechanisms available for the initiator, in decreasing preference order (favorite choice first).
このフィールドは、優先順位（最初のお気に入りの選択肢）を小さくするには、イニシエータために利用可能な1つまたは複数のセキュリティ・メカニズムが含まれています。
reqFlags
reqFlags
This field, if present, contains the service options that are requested to establish the context (the req_flags parameter of GSS_Init_sec_context()). This field is inherited from RFC 2478 and is not integrity protected. For implementations of this specification, the initiator SHOULD omit this reqFlags field and the acceptor MUST ignore this reqFlags field.
このフィールドは、存在する場合、コンテキスト（もしGSS_Init_sec_contextのreq_flagsを使用パラメータを（））を確立するように要求されているサービスオプションが含まれています。このフィールドは、RFC 2478から継承し、完全性保護されていないです。この仕様の実装のために、開始剤は、このreqFlagsフィールドを省略しなければならず、アクセプタこのreqFlagsフィールドを無視しなければなりません。
The size constraint on the ContextFlags ASN.1 type only applies to the abstract type. The ASN.1 DER requires that all trailing zero bits be truncated from the encoding of a bit string type whose abstract definition includes named bits. Implementations should not expect to receive exactly 32 bits in an encoding of ContextFlags.
ContextFlagsのASN.1タイプのサイズの制約は抽象型に適用されます。 ASN.1のDERは、すべての後続ゼロのビットが抽象定義名前ビットを含むビット列型のエンコーディングから切り捨てられることを必要とします。実装はContextFlagsのエンコーディングに正確32ビットを受信するように期待すべきではありません。
mechToken
mechToken
This field, if present, contains the optimistic mechanism token.
このフィールドは、存在する場合、楽観的メカニズムのトークンが含まれています。
mechlistMIC
mechlistMIC
This field, if present, contains an MIC token for the mechanism list in the initial negotiation message. This MIC token is computed according to Section 5.
このフィールドは、存在する場合、最初のネゴシエーションメッセージ内メカニズムリストのMICトークンが含まれています。このMICトークンは、第5節に従って計算されます。
NegTokenResp ::= SEQUENCE {
negState [0] ENUMERATED {
accept-completed (0),
accept-incomplete (1),
reject (2),
request-mic (3)
} OPTIONAL,
-- REQUIRED in the first reply from the target
supportedMech [1] MechType OPTIONAL,
-- present only in the first reply from the target
responseToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL,
...
}
This is the syntax for all subsequent negotiation messages.
これは、以降のすべてのネゴシエーションメッセージの構文です。
negState
negState
This field, if present, contains the state of the negotiation. This can be:
このフィールドは、存在する場合、交渉の状態が含まれています。これは、ことができます。
accept-completed
受け入れ完了
No further negotiation message from the peer is expected, and the security context is established for the sender.
ピアからのさらなる交渉メッセージが予想されていない、とセキュリティコンテキストは、送信者のために確立されています。
accept-incomplete
受け入れ、不完全
At least one additional negotiation message from the peer is needed to establish the security context.
ピアから少なくとも1つの追加のネゴシエーションメッセージは、セキュリティコンテキストを確立するために必要とされます。
reject
拒絶します
The sender terminates the negotiation.
送信者は、交渉を終了します。
request-mic
要求 - マイク
The sender indicates that the exchange of MIC tokens, as described in Section 5, will be REQUIRED if per-message integrity services are available on the mechanism context to be established. This value SHALL only be present in the first reply from the target.
送信者がMICトークンの交換ていることを示し、セクション5に記載されているように、メッセージごとの完全性サービスを確立するためのメカニズムコンテキストに利用可能である場合、必要とされます。この値は、ターゲットからの最初の応答で存在しなければなりません。
This field is REQUIRED in the first reply from the target, and is OPTIONAL thereafter. When negState is absent, the actual state should be inferred from the state of the negotiated mechanism context.
このフィールドには、ターゲットからの最初の応答に必要とされ、その後はオプションです。 negStateが存在しない場合、実際の状態がネゴシエート機構コンテキストの状態から推測されるべきです。
supportedMech
supportedMech
This field SHALL only be present in the first reply from the target. It MUST be one of the mechanism(s) offered by the initiator.
このフィールドは、ターゲットからの最初の応答に存在しなければなりません。それは、イニシエータによって提供されるメカニズム（S）のいずれかでなければなりません。
ResponseToken
ResponseToken
This field, if present, contains tokens specific to the mechanism selected.
このフィールドは、存在する場合、選択された機構に固有のトークンが含まれています。
mechlistMIC
mechlistMIC
This field, if present, contains an MIC token for the mechanism list in the initial negotiation message. This MIC token is computed according to Section 5.
このフィールドは、存在する場合、最初のネゴシエーションメッセージ内メカニズムリストのMICトークンが含まれています。このMICトークンは、第5節に従って計算されます。
If the mechanism selected by the negotiation does not support integrity protection, then no mechlistMIC token is used.
交渉によって選択された機構は、完全性保護をサポートしていない場合は、何のmechlistMICトークンが使用されていません。
Otherwise, if the accepted mechanism is the most preferred mechanism of both the initiator and the acceptor, then the MIC token exchange, as described later in this section, is OPTIONAL. A mechanism is the acceptor's most preferred mechanism if there is no other mechanism that the acceptor would have preferred over the accepted mechanism had it been present in the mechanism list.
受け入れ機構がイニシエータとアクセプタの両方の最も好ましい機構である場合、このセクションで後述するように、そうでなければ、その後MICトークン交換は、任意です。それはメカニズムのリストに存在していたアクセプターが受け入れメカニズムよりも優先しているだろう、他のメカニズムが存在しない場合のメカニズムは、アクセプターの最も好ましいメカニズムです。
In all other cases, MIC tokens MUST be exchanged after the mechanism context is fully established.
機構コンテキストが完全に確立された後、他のすべての場合において、MICトークンを交換しなければなりません。
a) The mechlistMIC token (or simply the MIC token) is computed over the mechanism list in the initial negotiation message by invoking GSS_GetMIC() as follows: the input context_handle is the established mechanism context, the input qop_req is 0, and the input message is the DER encoding of the value of type MechTypeList, which is contained in the "mechTypes" field of the NegTokenInit. The input message is NOT the DER encoding of the type "[0] MechTypeList".
A）mechlistMICトークン（または単にMICトークン）は次のようにGSS_GetMIC（）を呼び出すことによって、初期ネゴシエーションメッセージにおける機構リストにわたって計算される：入力context_handleは、確立されたメカニズムのコンテキスト、入力qop_reqは、0であり、入力メッセージでありますNegTokenInitの「mechTypes」フィールドに含まれるタイプMechTypeListの値のDER符号化です。入力メッセージは、「[0] MechTypeList」タイプのDER符号化ではありません。
b) If the selected mechanism exchanges an even number of mechanism tokens (i.e., the acceptor sends the last mechanism token), the acceptor does the following when generating the negotiation message containing the last mechanism token: if the MIC token exchange is optional, GSS_Accept_sec_context() either indicates GSS_S_COMPLETE and does not include a mechlistMIC token, or indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token and an accept-incomplete state; if the MIC token exchange is required, GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token. Acceptors that wish to be compatible with legacy Windows SPNEGO implementations, as described in Appendix C, should not generate a mechlistMIC token when the MIC token exchange is not required. The initiator then processes the last mechanism token, and does one of the following:
機構トークンの偶数（すなわち、アクセプターが最後のメカニズムトークンを送信する）選択された機構を交換した場合、最後のメカニズムトークンを含むネゴシエーションメッセージを生成する際b）に示すように、アクセプターは次の処理を行いますMICトークン交換がオプションである場合、場合gss_accept_sec_context （）GSS_S_COMPLETE示し、mechlistMICトークンが含まれていない、またはGSS_S_CONTINUE_NEEDEDを示し、mechlistMICトークンと受け入れる不完全状態を含むいずれか。 MICトークン交換が必要な場合、場合gss_accept_sec_context（）はGSS_S_CONTINUE_NEEDEDを示し、mechlistMICトークンを含みます。 MICトークン交換が必要とされていない場合には、付録Cで説明したように、従来のWindows SPNEGOの実装と互換性があるように希望する受容体は、mechlistMICトークンを生成するべきではありません。イニシエータは、最後のメカニズムトークンを処理し、次のいずれかを実行します。
I) If a mechlistMIC token was included and is correctly
verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE.
The output negotiation message contains a mechlistMIC token
and an accept_complete state. The acceptor MUST then verify
this mechlistMIC token.
II) If a mechlistMIC token was included but is incorrect, the negotiation SHALL be terminated. GSS_Init_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
mechlistMICトークンが含まれているが間違っているた場合II）、交渉は終了するもの。もしGSS_Init_sec_context（）はGSS_S_DEFECTIVE_TOKENを示しています。
III) If no mechlistMIC token was included and the MIC token exchange is not required, GSS_Init_sec_context() indicates GSS_S_COMPLETE with no output token.
何mechlistMICトークンが含まれていなかったとMICトークン交換が必要とされない場合III）、もしGSS_Init_sec_context（）は出力トークンとともにGSS_S_COMPLETEを示しています。
IV) If no mechlistMIC token was included but the MIC token exchange is required, the negotiation SHALL be terminated. GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
何mechlistMICトークンが含まれていなかったが、MICトークンの交換が必要な場合IV）、交渉は終了するもの。場合gss_accept_sec_context（）はGSS_S_DEFECTIVE_TOKENを示しています。
c) In the case that the chosen mechanism exchanges an odd number of mechanism tokens (i.e., the initiator sends the last mechanism token), the initiator does the following when generating the negotiation message containing the last mechanism token: if the negState was request-mic in the first reply from the target, a mechlistMIC token MUST be included; otherwise, the mechlistMIC token is OPTIONAL. (Note that the MIC token exchange is required if a mechanism other than the initiator's first choice is chosen.) In the case that the optimistic mechanism token is the only mechanism token for the initiator's preferred mechanism, the mechlistMIC token is OPTIONAL. Whether the mechlistMIC token is included, GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED. Initiators that wish to be compatible with legacy Windows SPNEGO implementations, as described in Appendix C, should not generate a mechlistMIC token when the MIC token exchange is not required. The acceptor then processes the last mechanism token and does one of the following:
c）の場合には、その選択された機構交換機構トークン（すなわち、イニシエータが最後のメカニズムトークンを送信する）、開始剤がないの奇数最後機構トークンを含むネゴシエーションメッセージを生成する際に、以下：negStateが要求 - た場合ターゲットからの最初の応答、mechlistMICトークン内のマイクが含まれなければなりません。それ以外の場合は、mechlistMICトークンはオプションです。 （開始剤の最初の選択肢以外のメカニズムを選択した場合MICトークン交換が必要であることに注意してください。）楽観的機構トークンがイニシエータの好適な機構のための唯一のメカニズムトークンである場合には、mechlistMICトークンは任意です。 mechlistMICトークンが含まれているかどうか、もしGSS_Init_sec_context（）はGSS_S_CONTINUE_NEEDEDを示しています。付録Cで説明したように、従来のWindows SPNEGOの実装と互換性がしたいイニシエータ、MICトークン交換が必要とされていない場合mechlistMICトークンを生成するべきではありません。アクセプターは、トークンの最後のメカニズムを処理し、次のいずれかを実行します。
I) If a mechlistMIC token was included and is correctly
verified, GSS_Accept_sec_context() indicates GSS_S_COMPLETE.
The output negotiation message contains a mechlistMIC token
and an accept_complete state. The initiator MUST then verify
this mechlistMIC token.
II) If a mechlistMIC token was included but is incorrect, the negotiation SHALL be terminated. GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
mechlistMICトークンが含まれているが間違っているた場合II）、交渉は終了するもの。場合gss_accept_sec_context（）はGSS_S_DEFECTIVE_TOKENを示しています。
III) If no mechlistMIC token was included and the mechlistMIC token exchange is not required, GSS_Accept_sec_context() indicates GSS_S_COMPLETE. The output negotiation message contains an accept_complete state.
何mechlistMICトークンが含まれていなかったとmechlistMICトークン交換が必要とされない場合III）、場合gss_accept_sec_context（）はGSS_S_COMPLETEを示しています。出力交渉メッセージはaccept_complete状態が含まれています。
IV) In the case that the optimistic mechanism token is also the last mechanism token (when the initiator's preferred mechanism is accepted by the target) and the target sends a request-mic state but the initiator did not send a mechlistMIC token, the target then MUST include a mechlistMIC token in that first reply. GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received mechlistMIC token and generate a mechlistMIC token to send back to the target. The target SHALL, in turn, verify the returned mechlistMIC token and complete the negotiation.
IV）楽観的メカニズムトークンはまた、イニシエータの優先メカニズムがターゲットに受け入れられる最後のメカニズムトークン（）とターゲットである場合には、要求 - マイクの状態を送信しますが、イニシエータは、その後mechlistMICトークン、ターゲットを送信しませんでしたその最初の返信でmechlistMICトークンを含まなければなりません。場合gss_accept_sec_context（）はGSS_S_CONTINUE_NEEDEDを示しています。イニシエータは、受信mechlistMICトークンを確認し、バックターゲットに送信するmechlistMICトークンを生成しなければなりません。ターゲットは、順番に、返さmechlistMICトークンを検証し、交渉を完了しなければなりません。
V) If no mechlistMIC token was included and the acceptor sent a request-mic state in the first reply message (the exchange of MIC tokens is required), the negotiation SHALL be terminated. GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
何mechlistMICトークンが含まれていないとアクセプターが最初の応答メッセージ（MICトークンの交換が必要とされる）に要求マイク状態を送信された場合V）、ネゴシエーションは終了するもの。場合gss_accept_sec_context（）はGSS_S_DEFECTIVE_TOKENを示しています。
Two mechanisms are provided for extensibility. First, the ASN.1 structures in this specification MAY be expanded by IETF standards action. Implementations receiving unknown fields MUST ignore these fields.
2つのメカニズムが拡張性のために提供されています。まず、この仕様でASN.1構造は、IETF標準化行動によって拡張することができます。未知のフィールドを受け取る実装は、これらのフィールドを無視しなければなりません。
Secondly, OIDs corresponding to a desired mechanism attribute (i.e., mechanism variants) may be included in the set of preferred mechanisms by an initiator. The acceptor can choose to honor this request by preferring mechanisms that have the included attributes. Future work within the Kitten working group is expected to standardize common attributes that SPNEGO mechanisms may wish to support. At this time, it is sufficient to say that initiators MAY include OIDs that do not correspond to mechanisms. Such OIDs MAY influence the acceptor's choice of mechanism. As discussed in Section 5, if there are mechanisms that, if present in the initiator's list of mechanisms, might be preferred by the acceptor instead of the initiator's preferred mechanism, the acceptor MUST demand the MIC token exchange. As the consequence, acceptors MUST demand the MIC token exchange if they support negotiation of attributes not available in the initiator's preferred mechanism, regardless of whether the initiator actually requested these attributes.
第二に、所望の機構の属性（すなわち、機構変異体）に対応するOIDは、イニシエータが好ましいメカニズムのセットに含まれてもよいです。アクセプターは、付属の属性を持つメカニズムを好むことにより、この要求を称えるために選択することができます。子猫ワーキンググループ内の今後の作業がSPNEGOメカニズムをサポートすることを望むかもしれない共通の属性を標準化することが期待されます。このとき、イニシエータは、メカニズムに対応していないOIDを含むことができることを言うのに十分です。このようなOIDは、メカニズムのアクセプターの選択に影響を与える可能性があります。メカニズムのイニシエータのリストに存在する場合、代わりに開始剤の好適な機構の受容によって好まれるかもしれない、メカニズムがある場合、セクション5で説明したように、アクセプターは、MICトークン交換を要求しなければなりません。彼らは関係なく、イニシエータが、実際にこれらの属性を要求するかどうかの、イニシエータの優先メカニズムでは使用できない属性のネゴシエーションをサポートする場合は結果として、受容体は、MICトークンの交換を要求しなければなりません。
In order to produce the MIC token for the mechanism list, the mechanism must provide integrity protection. When the selected mechanism does not support integrity protection, the negotiation is vulnerable: an active attacker can force it to use a security mechanism that is not mutually preferred but is acceptable to the target.
メカニズムのリストについては、MICのトークンを生成するために、メカニズムは、完全性保護を提供する必要があります。選択された機構は、完全性保護をサポートしていない場合には、交渉は脆弱です：アクティブな攻撃者が相互に有利ではなく、ターゲットに許容されるセキュリティ・メカニズムを使用するように強制することができます。
This protocol provides the following guarantees when per-message integrity services are available on the established mechanism context, and the mechanism list was altered by an adversary such that a mechanism that is not mutually preferred could be selected:
このプロトコルは、メッセージごとの完全性サービスが確立されたメカニズムコンテキストに利用可能である場合は、次の保証を提供し、機構リストは互いに好ましくない機構を選択することができるように敵対することによって変更されました。
a) If the last mechanism token is sent by the initiator, both peers shall fail;
a）は、最後のメカニズムトークンは、イニシエータによって送信された場合は、両方のピアが失敗しなければなりません。
b) If the last mechanism token is sent by the acceptor, the acceptor shall not complete and the initiator, at worst, shall complete with its preferred mechanism being selected.
最後のメカニズムトークンがアクセプターによって送信された場合b）は、アクセプターが完了してはならないと、イニシエータは、最悪の場合、その好ましいメカニズムが選択された状態で完了しなければなりません。
The negotiation may not be terminated if an alteration was made but had no material impact.
変更が行われたが与える影響は軽微でなかった場合、交渉は終了しない場合があります。
The protection of the negotiation depends on the strength of the integrity protection. In particular, the strength of SPNEGO is no stronger than the integrity protection of the weakest mechanism acceptable to GSS-API peers.
交渉の保護は、完全性保護の強度に依存します。具体的には、SPNEGOの強さは、GSS-APIピアに許容可能な最も弱いメカニズムの完全性の保護よりも強いではありません。
Note that where there exist multiple mechanisms with similar context tokens, but different semantics, such that some or all of the mechanisms' context tokens can be easily altered so that one mechanism's context tokens may pass for another of the similar mechanism's context tokens, then there may exist a downgrade or similar attacks. For example, if a given family of mechanisms uses the same context token syntax for two or more variants and depends on the OID in the initial token's pseudo-ASN.1/DER wrapper, but does not provide integrity protection for that OID, then there may exist an attack against those mechanisms. SPNEGO does not generally defeat such attacks.
一つのメカニズムのコンテキストトークンがそこ、同様の機構のコンテキストトークンの別のために渡すことができるようにメカニズムコンテキストトークンの一部または全部を容易に変更することができるように、異なる意味が類似のコンテキストトークンを持つ複数のメカニズムが存在するが、ここでことに注意してくださいダウングレードまたは同様の攻撃を存在してもよいです。例えば、メカニズムの与えられた家族は、二つ以上の変異体のために同じコンテキストトークンの構文を使用している場合、最初のトークンの疑似ASN.1 / DERラッパーにOIDに依存しますが、その後そこに、そのOIDのための完全性保護を提供していませんそれらのメカニズムに対する攻撃を存在してもよいです。 SPNEGOは、一般的に、このような攻撃を敗北されません。
In all cases, the communicating peers are exposed to the denial of service threat.
すべての場合において、通信ピアは、サービスの脅威の拒否にさらされています。
The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn, Martin Rex, Jeff Altman, Tom Yu, Cristian Ilac, Simon Spero, and Bill Sommerfeld for their comments and suggestions during the development of this document.
作者はこのドキュメントの開発中に自分の意見や提案をサム・ハートマン、ニコラス・ウィリアムズ、ケン・レイバーン、マーティン・レックス、ジェフ・アルトマン、トム・ゆう、クリスティアンILAC、サイモン・スペロ、およびビル・ゾンマーフェルトに感謝したいです。
Luke Howard provided a prototype of this protocol in Heimdal and resolved several issues in the initial version of this document.
ルークハワードはHeimdalの中で、このプロトコルのプロトタイプを提供し、この文書の初期のバージョンではいくつかの問題を解決しました。
Eric Baize and Denis Pinkas wrote the original SPNEGO specification [RFC2478] of which some of the text has been retained in this document.
エリック・ベーズとデニスピンカスは、テキストの一部は、この文書に保持されているのオリジナルSPNEGO仕様[RFC2478]を書きました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート1"、RFC 2743、2000年1月。
[X690] 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 International Standard 8825-1:1998.
[X690] ASN.1符号化ルール：基本符号化規則（BER）の仕様、正規符号化規則（CER）と識別符号化規則（DER）、ITU-T勧告X.690（1997）| ISO / IEC国際規格8825から1：1998。
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, December 1998.
[RFC2478]ベーズ、E.およびD.ピンカス、 "単純で保護されたGSS-API交渉メカニズム"、RFC 2478、1998年12月。
Appendix A. SPNEGO ASN.1 Module
付録A. SPNEGO ASN.1モジュール
SPNEGOASNOneSpec {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanism(5) snego (2) modules(4) spec2(2)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
MechType ::= OBJECT IDENTIFIER
-- OID represents each security mechanism as suggested by
-- [RFC2743]
MechTypeList ::= SEQUENCE OF MechType
NegotiationToken ::= CHOICE {
negTokenInit [0] NegTokenInit,
negTokenResp [1] NegTokenResp
}
NegTokenInit ::= SEQUENCE {
mechTypes [0] MechTypeList,
reqFlags [1] ContextFlags OPTIONAL,
-- inherited from RFC 2478 for backward compatibility,
-- RECOMMENDED to be left out
mechToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL,
...
}
NegTokenResp ::= SEQUENCE {
negState [0] ENUMERATED {
accept-completed (0),
accept-incomplete (1),
reject (2),
request-mic (3)
} OPTIONAL,
-- REQUIRED in the first reply from the target
supportedMech [1] MechType OPTIONAL,
-- present only in the first reply from the target
responseToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL,
...
}
ContextFlags ::= BIT STRING {
delegFlag (0),
mutualFlag (1),
replayFlag (2),
sequenceFlag (3),
anonFlag (4), confFlag (5),
integFlag (6)
} (SIZE (32))
END
終わり
Appendix B. GSS-API Negotiation Support API
付録B. GSS-API交渉のサポートAPI
In order to provide to a GSS-API caller (the initiator or the target or both) with the ability to choose among the set of supported mechanisms, a reduced set of mechanisms for negotiation and two additional APIs are defined:
サポート機構のセットの中から選択する能力を有するGSS-APIの呼び出し元（イニシエータまたはターゲットまたは両方）に提供するために、交渉するための機構と二つの追加のAPIの縮小セットが定義されています。
o GSS_Get_neg_mechs() indicates the set of security mechanisms available on the local system to the caller for negotiation, for which appropriate credentials are available.
O GSS_Get_neg_mechs（）は、適切な資格情報が利用可能なネゴシエーションの発信者にローカルシステム上で利用可能なセキュリティメカニズムのセットを示しています。
o GSS_Set_neg_mechs() specifies the set of security mechanisms to be used on the local system by the caller for negotiation, for the given credentials.
O GSS_Set_neg_mechs（）は、与えられた資格情報、交渉のための発信者がローカル・システムで使用されるセキュリティメカニズムのセットを指定します。
B.1. GSS_Set_neg_mechs Call
B.1。 GSS_Set_neg_mechsコール
Inputs:
入力：
o cred_handle CREDENTIAL HANDLE, -- NULL specifies default -- credentials o mech_set SET OF OBJECT IDENTIFIER
O cred_handle資格HANDLE、 - NULLデフォルトを指定する - オブジェクト識別子のmech_set SET O資格情報
Outputs:
出力：
o major_status INTEGER, o minor_status INTEGER
minor_status INTEGER〇〇major_status INTEGER、
Return major_status codes:
major_status戻りコード：
o GSS_S_COMPLETE indicates that the set of security mechanisms available for negotiation has been set to mech_set. o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
O GSS_S_COMPLETEは、交渉のために利用可能なセキュリティメカニズムのセットがmech_setに設定されていることを示しています。 O GSS_S_FAILUREは、要求された操作がGSS-APIレベルで不特定の理由で実行できなかったことを示しています。
This allows callers to specify the set of security mechanisms that may be negotiated with the credential identified by cred_handle. This call is intended to support specialized callers who need to restrict the set of negotiable security mechanisms from the set of all security mechanisms available to the caller (based on available credentials). Note that if more than one mechanism is specified in mech_set, the order in which those mechanisms are specified implies a relative preference.
これは、発信者がcred_handleによって識別クレデンシャルと交渉することができるセキュリティ機構のセットを指定することを可能にします。この呼び出しは（利用可能な資格情報に基づいて）、発信者が利用可能なすべてのセキュリティ・メカニズムのセットから交渉のセキュリティメカニズムのセットを制限する必要が専門の発信者をサポートすることを目的としています。複数の機構がmech_setで指定されている場合、これらのメカニズムが指定される順序は、相対的優先度を含意することに注意してください。
B.2. GSS_Get_neg_mechs Call
B.2。 GSS_Get_neg_mechsコール
Input:
入力：
o cred_handle CREDENTIAL HANDLE -- NULL specifies default -- credentials
O cred_handle資格HANDLE - NULLデフォルトを指定する - 資格情報
Outputs:
出力：
o major_status INTEGER, o minor_status INTEGER, o mech_set SET OF OBJECT IDENTIFIER
minor_status INTEGER、オブジェクト識別子のO mech_set SET〇〇major_status INTEGER、
Return major_status codes:
major_status戻りコード：
o GSS_S_COMPLETE indicates that the set of security mechanisms available for negotiation has been returned in mech_set.
O GSS_S_COMPLETEは、交渉のために利用可能なセキュリティメカニズムのセットがmech_setに戻ってきたことを示しています。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
O GSS_S_FAILUREは、要求された操作がGSS-APIレベルで不特定の理由で実行できなかったことを示しています。
This allows callers to determine the set of security mechanisms available for negotiation with the credential identified by cred_handle. This call is intended to support specialized callers who need to reduce the set of negotiable security mechanisms from the set of supported security mechanisms available to the caller (based on available credentials).
これは、発信者がcred_handleで識別資格との交渉のために利用可能なセキュリティメカニズムのセットを決定することができます。この呼び出しは（利用可能な資格情報に基づいて）、発信者が利用可能なサポートされているセキュリティ・メカニズムのセットから交渉のセキュリティメカニズムのセットを削減する必要が専門の発信者をサポートすることを目的としています。
Note: The GSS_Indicate_mechs() function indicates the full set of mechanism types available on the local system. Since this call has no input parameter, the returned set is not necessarily available for all credentials.
注：は、gss_indicate_mechs（）関数は、ローカルシステム上で利用可能なメカニズムのタイプのフルセットを示しています。この呼び出しは何も入力パラメータを持っていないので、返されたセットは、必ずしもすべての資格情報では使用できません。
Appendix C. Changes since
付録C.からの変更点
SPNEGO implementations in Microsoft Windows 2000/Windows XP/Windows Server 2003 have the following behavior: no mechlistMIC is produced and mechlistMIC is not processed if one is provided; if the initiator sends the last mechanism token, the acceptor will send back a negotiation token with an accept_complete state and no mechlistMIC token. In addition, an incorrect OID (1.2.840.48018.1.2.2) can be used to identify the GSS-API Kerberos Version 5 mechanism.
Microsoft WindowsのSPNEGOの実装2000 / WindowsのXP / Windows Server 2003には、次の動作を持っている：なしmechlistMICが生成されていないと1が設けられている場合mechlistMICは処理されません。イニシエータが最後のメカニズムトークンを送信した場合、アクセプタはaccept_complete状態となしmechlistMICトークンとの交渉トークンを返送します。また、誤ったOID（1.2.840.48018.1.2.2）はGSS-API Kerberosバージョン5メカニズムを同定するために使用することができます。
The following changes have been made to be compatible with these legacy implementations.
次の変更は、これらの従来の実装と互換性があるように行われています。
* NegTokenTarg is changed to negTokenResp and is the message format for all subsequent negotiation tokens.
* NegTokenTargはnegTokenRespに変更し、それ以降のすべての交渉トークンのメッセージ形式です。
* NegTokenInit is the message for the initial negotiation message, and only that message.
* NegTokenInitは最初のネゴシエーションメッセージのメッセージ、そして唯一のそのメッセージです。
* mechTypes in negTokenInit is not optional.
* negTokenInitでmechTypesはオプションではありません。
* If the selected mechanism is also the most preferred mechanism for both peers, it is safe to omit the MIC tokens.
*選択された機構は、MICトークンを省略しても安全である、また、両方のピアのための最も好ましいメカニズムである場合。
If at least one of the two peers implements the updated pseudo mechanism in this document, the negotiation is protected.
2つのピアの少なくとも一方が、この文書の更新擬似メカニズムを実装している場合、ネゴシエーションが保護されています。
The following changes are to address problems in RFC 2478.
次の変更は、RFC 2478での問題に対処するためです。
* reqFlags is not protected, therefore it should not impact the negotiation.
* reqFlagsは、したがって、それが交渉に影響を与えるべきではありません、保護されていません。
* DER encoding is required.
* DERエンコーディングが必要です。
* GSS_GetMIC() input is clarified.
* GSS_GetMIC（）入力が明確にされています。
* Per-message integrity services are requested for the negotiated mechanism.
*メッセージごとの完全性サービスは、ネゴシエートメカニズムのために要求されています。
* Two MIC tokens are exchanged, one in each direction.
*二つのMICトークンは、各方向に1つずつ交換しています。
An implementation that conforms to this specification will not inter-operate with a strict RFC 2748 implementation. Even if the new implementation always sends a mechlistMIC token, it will still fail to inter-operate. If it is a server, it will fail because it requests a mechlistMIC token using an option that older implementations do not support. Clients will tend to fail as well.
この仕様に準拠した実装は厳密RFC 2748実装と相互動作しません。新しい実装は常にmechlistMICトークンを送信した場合でも、それはまだ相互運用に失敗します。それがサーバである場合、それは古い実装がサポートしていないというオプションを使用してmechlistMICトークンを要求するので、それは失敗します。クライアントは、同様に失敗する傾向があります。
As an alternative to the approach chosen in this specification, we could have documented a correct behavior that is fully backward compatible with RFC 2478 and included an appendix on how to inter-operate with existing incorrect implementations of RFC 2478.
この仕様で選択されたアプローチに代わるものとして、私たちは、RFC 2478との完全な下位互換性があるとRFC 2478の既存の間違った実装と相互運用する方法については、付録を含め、正しい行動を文書化した可能性があります。
As a practical matter, the SPNEGO implementers within the IETF have valued interoperability with the Microsoft implementations. We were unable to choose to maintain reasonable security guarantees, to maintain interoperability with the Microsoft implementations, and to maintain interoperability with correct implementations of RFC 2478.
実際問題として、IETF内のSPNEGOの実装は、Microsoftの実装との相互運用性を高く評価しています。当社は、合理的な安全保障を維持するために、Microsoftの実装との相互運用性を維持するため、およびRFC 2478の正しい実装との相互運用性を維持するために選択することができませんでした。
The working group was not aware of any RFC 2478 implementations deployed on the Internet. Even if there are such implementations, it is unlikely that they will inter-operate because of a critical flaw in the description of the encoding of the mechanism list in RFC 2478.
ワーキンググループは、インターネット上でデプロイされたRFC 2478個の実装を認識していませんでした。そのような実装がある場合でも、彼らが原因RFC 2478で機構リストのエンコーディングの説明では、重要な欠陥の相互運用することはほとんどありません。
With the approach taken in this specification, security is ensured between new implementations all the time while maintaining interoperability with the implementations deployed within the IETF community. The working group believes that this justifies breaking compatibility with a correct implementation of RFC 2478.
IETFコミュニティ内に配備実装との相互運用性を維持しながら、この仕様で撮影したアプローチにより、セキュリティが新たに実装間のすべての時間を確保しています。ワーキンググループでは、これはRFC 2478の正しい実装との互換性の破壊を正当化すると考えています。
Appendix D. mechListMIC Computation Example
付録D. mechListMIC計算例
The following is an example to illustrate how the mechListMIC field would be computed.
次はmechListMICフィールドが計算される方法を説明するための一例です。
The initial part of the DER encoding of NegTokenInit is constructed as follows (the "nn" are length encodings, possibly longer than one octet):
（「NN」は、おそらく長い1つのオクテットよりも、長符号化されている）は、以下のようにNegTokenInitのDER符号化の最初の部分を構成しています。
30 -- identifier octet for constructed SEQUENCE (NegTokenInit) nn -- length
長さ - 30 - 構築SEQUENCE（NegTokenInit）NNの識別子オクテット
-- contents octets of the SEQUENCE begin with -- DER encoding of "[0] MechTypeList": A0 -- identifier octet for constructed [0] nn -- length
- 配列の内容オクテットで始まる - "[0] MechTypeList" のDERエンコーディング：A0 - 構築するための識別子オクテット[0] NN - 長さ
-- contents of the constructed [0] are DER encoding
-- of MechTypeList (which is a SEQUENCE):
30 -- identifier octet for constructed SEQUENCE
nn -- length
-- contents octets of the SEQUENCE begin with -- DER encoding of OBJECT IDENTIFIER: 06 -- identifier octet for primitive OBJECT IDENTIFIER 09 -- length 2A 86 48 86 F7 12 01 02 02 -- Kerberos V5 -- {1 2 840 113554 1 2 2}
- 配列の内容オクテットで始まる - オブジェクト識別子のDERエンコーディング：06 - 長2A 86 48 86 F7 12 01 02 02 - - ケルベロスV5 - {1 2 840 113554プリミティブオブジェクト識別子09の識別子オクテットを1 2 2}
If a mechlistMIC needs to be generated (according to the rules in Section 5), it is computed by using the DER encoding of the type MechTypeList data from the initiator's NegTokenInit token as input to the GSS_GetMIC() function. In this case, the MIC would be computed over the following octets:
mechlistMIC（セクション5の規則に従って）発生する必要がある場合、それはGSS_GetMIC（）関数への入力としてイニシエータのNegTokenInitトークンから型MechTypeListデータのDER符号化を使用して計算されます。この場合、MICは、以下のオクテットにわたって計算されます：
DER encoding of MechTypeList: 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...
MechTypeListのDERエンコーディング：30 NN 06 09 2A 86 48 86 F7 12 01 02 02 ...
Note that the identifier octet and length octet(s) for constructed [0] (A0 nn) are not included in the MIC computation.
構築[0]（A0のNN）の識別子オクテット長さオクテット（単数または複数）MIC計算に含まれないことに留意されたいです。
Authors' Addresses
著者のアドレス
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
ラリー朱マイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052米国
EMail: lzhu@microsoft.com
メールアドレス：lzhu@microsoft.com
Paul Leach Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
ポール・リーチマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052米国
EMail: paulle@microsoft.com
メールアドレス：paulle@microsoft.com
Karthik Jaganathan Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
カルティクJaganathanマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052米国
EMail: karthikj@microsoft.com
メールアドレス：karthikj@microsoft.com
Wyllys Ingersoll Sun Microsystems 1775 Wiehle Avenue, 2nd Floor Reston, VA 20190 US
WyllysインガーソルSun Microsystemsの1775 Wiehleアベニュー、2階レストン、バージニア州20190米国
EMail: wyllys.ingersoll@sun.com
メールアドレス：wyllys.ingersoll@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。