[要約] RFC 4178は、GSS-APIの交渉メカニズムに関するものであり、セキュリティサービスのアプリケーションプログラムインターフェースの簡単で保護された汎用の交渉メカニズムを提供することを目的としています。
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
シンプルで保護されたジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）ネゴシエーションメカニズム
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントは、RFC 2743で説明されているジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）のネゴシエーションメカニズムを指定します。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ピアが共通のセキュリティメカニズムを持っているかどうかを確立できる方法を規定していません。
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）メカニズムは、GSS-APIピアがその資格情報が1つ以上の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メカニズムのネゴシエーションは、次のモデルに基づいています。イニシエーターは、セキュリティメカニズムのリストを提案します。優先順位（お気に入りの選択肢のお気に入り）、アクセプター（ターゲットとも呼ばれる）は、イニシエーターの好みのセキュリティメカニズムを受け入れます（ターゲットとも呼ばれます）リストの最初）または提供されたリストから利用可能なメカニズムの1つを選択します。どちらも受け入れられない場合、アクセプターは提案された値を拒否します。次に、ターゲットはイニシエーターにその選択を通知します。
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）トークンを交換して、メカニズムリストが変更されていないことを確認します。攻撃者の行動が交渉の結果を実質的に変更できなかった場合、マイクトークンの交換はオプションです（セクション5を参照）。この場合、マイクトークンをオプションにすることで、既存の実装との相互運用性が提供され、交渉を保護します。この相互運用性は、複雑さの増加を犠牲にしてもたらされます。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
次に、ターゲットはイニシエーターからトークンを処理します。これにより、返信メッセージで返される可能性のある4つの状態（セクション4.2.2で定義されています）の1つが表示されます。拒否状態は交渉を終了します。受け入れられた状態は、イニシエーター選択メカニズムがターゲットに受け入れられ、最初のネゴシエーションメッセージに埋め込まれたセキュリティメカニズムが認証を完了するのに十分であることを示しています。受け入れられない状態は、さらなるメッセージ交換が必要であることを示していますが、マイクトークン交換（セクション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.
優先順序がアプリケーションによって指定されていない限り、ターゲットがメカニズムを選択するポリシーは、実装固有のローカル問題です。アプリケーションに指定された優先順序またはその他のポリシーがない場合、ターゲットは、有効な資格情報を備えたイニシエーター提案リストの最初のメカニズムを選択するものとします。
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.
最後に、マイクトークンを交換して、ターゲットが受け取ったメカニズムリストの信頼性を確保することができます。
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によるマイクトークンの使用との競合を回避するには、部分的に確立されたコンテキストを使用しても、メッセージを使用してはいけません。これを保証するために、gss_init_sec_context（）およびgss_accept_sec_context（）からの返されたときに、prot_ready_state [rfc2743]を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で定義）。（このメカニズムトークンは、このドキュメントの楽観的なメカニズムトークンと呼ばれます。）さらに、楽観的メカニズムを使用すると、トークンを使用すると、イニシエーターは、メカニズムを選択する前に最初のメカニズムトークンを生成しようとするときに遭遇した非脂肪誤差から回復できます。。イニシエーターの優先メカニズムが、その生成のかなりのコストのためにアクセプターによって選択される可能性が低い場合、実装は楽観的なメカニズムトークンを省略する可能性があります。
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イニシエーターは、通常どおりGSS_INIT_SEC_CONTEXT（）を呼び出しますが、SPNEGOを使用することを要求します。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.
i）提案されたメカニズムのいずれも受け入れられない場合、交渉は終了するものとする。gss_accept_sec_contextはgss_s_bad_mechを示します。アクセプターは、拒否状態を含む交渉トークンを出力する場合があります。
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), GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED. The acceptor MUST output a negotiation token containing a request-mic state.
ii）イニシエーターの優先メカニズムがターゲットによって受け入れられないか、このメカニズムが受け入れられているが、アクセプターの最も好ましいメカニズムではない場合（つまり、セクション5で説明されているようにマイクトークン交換が必要です）、GSS_ACCEPT_SEC_CONTEXT（）はGSS_S_CONTINUE_NEEDEDEDを示します。アクセプターは、リクエスト-MIC状態を含むネゴシエーショントークンを出力する必要があります。
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）それ以外の場合、このコンテキストを確立するためにイニシエーターから少なくとも1つの追加の交渉トークンが必要な場合、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_CONTEXTを示し、Accect_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-API規則に従って継続されます。選択したメカニズムのトークンは、GSS_S_Completeがイニシエーターとターゲットの両方に対して返されるまで、ネゴシエーションメッセージにカプセル化されます（セクション4を参照）。選択されたセキュリティメカニズム。
e) MIC tokens are then either skipped or exchanged according to Section 5.
e) マイクトークンは、セクション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.
コンテキスト確立の *_REQ_FLAG入力パラメーターは、 *_STATE出力パラメーターと同様に、選択したメカニズムに関連していることに注意してください。つまり、これらのパラメーターは交渉プロセス自体には適用されません。
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.
SPNEGOメカニズムのGSS-API資格情報が取得される場合、実装は、プリンシパルが利用可能なすべてのメカニズムを持っているすべてのメカニズムの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].
SPNEGOプロトコルメッセージのエンコードは、[X690]で説明されているように、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]によると、1つの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で定義されている初期コンテキストの構文に従います。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
メカプ
This field contains one or more security mechanisms available for the initiator, in decreasing preference order (favorite choice first).
このフィールドには、優先順位を減らすために、イニシエーターが利用できる1つ以上のセキュリティメカニズムが含まれています（Favorite Choice First）。
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
メクトケン
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.
このフィールドは、存在する場合、最初のネゴシエーションメッセージにメカニズムリストのマイクトークンが含まれています。このマイクトークンは、セクション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
ネグテート
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
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.
送信者は、セクション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.
このフィールドは、ターゲットからの最初の返信にのみ存在します。これは、イニシエーターが提供するメカニズムの1つでなければなりません。
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.
このフィールドは、存在する場合、最初のネゴシエーションメッセージにメカニズムリストのマイクトークンが含まれています。このマイクトークンは、セクション5に従って計算されます。
If the mechanism selected by the negotiation does not support integrity protection, then no mechlistMIC token is used.
交渉によって選択されたメカニズムが整合性保護をサポートしていない場合、メカリズムトークンは使用されません。
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.
それ以外の場合、受け入れられたメカニズムがイニシエーターとアクセプターの両方の最も好ましいメカニズムである場合、このセクションで説明したように、マイクトークン交換はオプションです。メカニズムは、メカニズムリストに存在していれば受容体が受け入れられたメカニズムよりも優先される他のメカニズムがない場合、アクセプターの最も好ましいメカニズムです。
In all other cases, MIC tokens MUST be exchanged after the mechanism context is fully established.
他のすべての場合、メカニズムのコンテキストが完全に確立された後、マイクトークンを交換する必要があります。
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トークン（または単にマイクトークン）は、gss_getmic（）を次のように呼び出すことにより、最初のネゴシエーションメッセージのメカニズムリストを介して計算されます。入力コンテキスト_handleは確立されたメカニズムコンテキストであり、入力qop_reqは0であり、入力メッセージは入力メッセージは0ですnegtokeninitの「メカプス」フィールドに含まれるタイプ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) 選択したメカニズムが偶数のメカニズムトークン（つまり、アクセプターが最後のメカニズムトークンを送信する）を交換する場合、アクセプターは最後のメカニズムトークンを含むネゴシエーションメッセージを生成するときに次のことを行います。GSS_S_COMPLETEを示し、MechListmic Tokenを含めないか、GSS_S_CONTINUE_NEEDEDを示し、メカリズムトークンと受け入れが含まれる状態を含む。マイクトークン交換が必要な場合、gss_accept_sec_context（）はgss_s_continue_neededを示し、mechlistmicトークンを含みます。付録Cに記載されているように、レガシーWindows SPNEGOの実装と互換性があることを希望するアクセプターは、マイクトークン交換が不要な場合にメカリズムトークンを生成しないでください。イニシエーターは、最後のメカニズムトークンを処理し、次のいずれかを実行します。
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.
i）Mechlistmicトークンが含まれ、正しく検証されている場合、gss_init_sec_context（）はgss_s_completeを示します。出力ネゴシエーションメッセージには、MechListmic TokenとAccept_Complete状態が含まれています。アクセプターは、このメカリズムトークンを検証する必要があります。
II) If a mechlistMIC token was included but is incorrect, the negotiation SHALL be terminated. GSS_Init_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
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.
iii）Mechlistmicトークンが含まれておらず、マイクトークン交換が不要な場合、GSS_INIT_SEC_CONTEXT（）は、出力トークンのないGSS_S_CONTEXT（）を示します。
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.
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) 選択したメカニズムが奇数のメカニズムトークンを交換する場合（つまり、イニシエーターは最後のメカニズムトークンを送信します）、イニシエーターは最後のメカニズムトークンを含むネゴシエーションメッセージを生成するときに次のことを行います：ネグテートがリクエストされた場合ターゲットからの最初の返信、メカリズムトークンを含める必要があります。それ以外の場合、メカリズムトークンはオプションです。（イニシエーターの最初の選択以外のメカニズムが選択されている場合、マイクトークン交換が必要であることに注意してください。）楽観的メカニズムトークンがイニシエーターの好ましいメカニズムの唯一のメカニズムトークンである場合、メカリストトークンはオプションです。mechlistmicトークンが含まれているかどうかにかかわらず、gss_init_sec_context（）はgss_s_continue_neededを示します。付録Cに記載されているように、レガシーWindows SPNEGOの実装と互換性があることを希望するイニシエーターは、マイクトークン交換が不要な場合にメカリストトークンを生成しないでください。その後、アクセプターは最後のメカニズムトークンを処理し、次のいずれかを実行します。
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.
i）Mechlistmicトークンが含まれ、正しく検証されている場合、gss_accept_sec_context（）はgss_s_completeを示します。出力ネゴシエーションメッセージには、MechListmic TokenとAccept_Complete状態が含まれています。イニシエーターは、このメカリズムトークンを検証する必要があります。
II) If a mechlistMIC token was included but is incorrect, the negotiation SHALL be terminated. GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
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.
iii）Mechlistmicトークンが含まれておらず、Mechlistmicトークン交換が必要ない場合、gss_accept_sec_context（）はgss_s_completeを示します。出力ネゴシエーションメッセージには、Accect_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）楽観的なメカニズムトークンが最後のメカニズムトークンである場合（イニシエーターの優先メカニズムがターゲットによって受け入れられている場合）、ターゲットはリクエストマイク状態を送信しますが、イニシエーターはメカリストトークンを送信しませんでした。その最初の返信にメカリズムトークンを含める必要があります。gss_accept_sec_context（）は、gss_s_continue_neededを示します。イニシエーターは、受信したメカリズムトークンを検証し、メカリズムトークンを生成してターゲットに送り返す必要があります。ターゲットは、返されたメカリズムトークンを検証し、交渉を完了するものとします。
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.
v）Mechlistmicトークンが含まれておらず、アクセプターが最初の返信メッセージ（MICトークンの交換が必要）でリクエスト-MIC状態を送信した場合、交渉は終了するものとします。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で説明したように、イニシエーターのメカニズムリストに存在する場合、イニシエーターの優先メカニズムの代わりにアクセプターが好む可能性がある場合、アクセプターはマイクトークン交換を要求する必要があります。結果として、開始者が実際にこれらの属性を要求したかどうかに関係なく、開始者の優先メカニズムで利用できない属性の交渉をサポートする場合、アクセプターはマイクトークン交換を要求する必要があります。
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.
メカニズムリスト用のマイクトークンを生成するために、メカニズムは整合性保護を提供する必要があります。選択したメカニズムが整合性保護をサポートしない場合、交渉は脆弱です。アクティブな攻撃者は、相互に好まず、ターゲットに受け入れられるセキュリティメカニズムを使用するように強制することができます。
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.
類似のコンテキストトークンを持つ複数のメカニズムが存在するが、メカニズムのコンテキストトークンの一部またはすべてが簡単に変更できるようにするため、1つのメカニズムのコンテキストトークンが別のメカニズムのコンテキストトークンに合格する可能性があることに注意してください。ダウングレードまたは同様の攻撃が存在する場合があります。たとえば、特定のメカニズムファミリーが2つ以上のバリアントに対して同じコンテキストトークン構文を使用し、最初のトークンの擬似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.
著者は、この文書の開発中のコメントと提案について、サム・ハートマン、ニコラス・ウィリアムズ、ケン・レーバーン、ケン・レーバーン、マーティン・レックス、トム・ユー、クリスティアン・イラック、サイモン・スペロ、ビル・ソマーフェルドに感謝したいと考えています。
Luke Howard provided a prototype of this protocol in Heimdal and resolved several issues in the initial version of this document.
Luke Howardは、Heimdalでこのプロトコルのプロトタイプを提供し、このドキュメントの初期バージョンでいくつかの問題を解決しました。
Eric Baize and Denis Pinkas wrote the original SPNEGO specification [RFC2478] of which some of the text has been retained in this document.
Eric BaizeとDenis Pinkasは、このドキュメントにテキストの一部が保持されている元のSpnego仕様[RFC2478]を書きました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743] Linn、J。、「Generic Security Service Application Program Interfaceバージョン2、Update 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 International Standard 8825-1：1998。
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, December 1998.
[RFC2478] Baize、E。およびD. Pinkas、「シンプルで保護されたGSS-API交渉メカニズム」、RFC 2478、1998年12月。
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
終わり
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発信者（イニシエーターまたはターゲットまたはその両方）に提供するために、交渉のメカニズムの削減と2つの追加の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（）指定された資格情報については、交渉のために呼び出し者がローカルシステムで使用するセキュリティメカニズムのセットを指定します。
Inputs:
入力：
o cred_handle CREDENTIAL HANDLE, -- NULL specifies default -- credentials o mech_set SET OF OBJECT IDENTIFIER
o cred_handle資格情報、 - nullはデフォルトを指定します - 資格情報o mech_setオブジェクト識別子のセット
Outputs:
出力：
o major_status INTEGER, o minor_status INTEGER
o Major_status integer、o minor_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で複数のメカニズムが指定されている場合、それらのメカニズムが指定される順序は相対的な好みを意味することに注意してください。
Input:
入力：
o cred_handle CREDENTIAL HANDLE -- NULL specifies default -- credentials
o CRED_HANDLE資格情報 - NULLはデフォルトを指定 - 資格情報を指定します
Outputs:
出力：
o major_status INTEGER, o minor_status INTEGER, o mech_set SET OF OBJECT IDENTIFIER
o Major_status Integer、o minor_status integer、o mech_setオブジェクト識別子セット
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（）関数は、ローカルシステムで利用可能なメカニズムタイプの完全なセットを示します。この呼び出しには入力パラメーターがないため、返されたセットは必ずしもすべての資格情報で使用できるわけではありません。
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 2000/Windows XP/Windows Server 2003でのSPNEGOの実装には、次の動作があります。MechListmicは生成されず、Mechlistmicが提供された場合は処理されません。イニシエーターが最後のメカニズムトークンを送信した場合、アクセプターはAccept_Complete状態とメカリズムトークンを使用してネゴシエーショントークンを送り返します。さらに、誤った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のメカタイプはオプションではありません。
* If the selected mechanism is also the most preferred mechanism for both peers, it is safe to omit the MIC tokens.
* 選択したメカニズムが両方のピアにとって最も好ましいメカニズムである場合、マイクトークンを省略することは安全です。
If at least one of the two peers implements the updated pseudo mechanism in this document, the negotiation is protected.
2つのピアのうち少なくとも1つがこのドキュメントで更新された擬似メカニズムを実装している場合、交渉は保護されています。
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.
* 2つのマイクトークンが交換され、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実装とは相互に操作されません。新しい実装が常にメカリズムトークンを送信したとしても、それでも操作性は依然として失敗します。サーバーの場合、古い実装ではサポートされていないオプションを使用してメカリストトークンを要求するため、失敗します。クライアントも失敗する傾向があります。
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の正しい実装で互換性を破ることを正当化すると考えています。
The following is an example to illustrate how the mechListMIC field would be computed.
以下は、メカリズムフィールドがどのように計算されるかを示す例です。
The initial part of the DER encoding of NegTokenInit is constructed as follows (the "nn" are length encodings, possibly longer than one octet):
NegTokenInitのderエンコードの最初の部分は、次のように構築されます（「nn」は長さのエンコーディングであり、おそらく1オクテットよりも長いです）：
30 -- identifier octet for constructed SEQUENCE (NegTokenInit) nn -- length
30-構築されたシーケンスの識別子オクテット（negtokeninit）nn-長さ
-- contents octets of the SEQUENCE begin with
-- DER encoding of "[0] MechTypeList":
A0 -- identifier octet for constructed [0]
nn -- length
-- 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}
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エンコードを使用して計算されます。この場合、マイクは次のオクテットで計算されます。
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
Larry Zhu Microsoft Corporation One Microsoft Way Redmond、WA 98052 US
EMail: lzhu@microsoft.com
Paul Leach Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Paul Leach Microsoft Corporation One Microsoft Way Redmond、WA 98052 US
EMail: paulle@microsoft.com
Karthik Jaganathan Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Karthik Jaganathan Microsoft Corporation One Microsoft Way Redmond、WA 98052 US
EMail: karthikj@microsoft.com
Wyllys Ingersoll Sun Microsystems 1775 Wiehle Avenue, 2nd Floor Reston, VA 20190 US
Wyllys Ingersoll Sun Microsystems 1775 Wiehle Avenue、2階のレストン、バージニア州20190米国
EMail: wyllys.ingersoll@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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 currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。