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
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).
版权所有（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.
本文件规定了通用安全服务应用程序接口（GSS-API）的协商机制，如RFC 2743所述。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，以修复该规范中的缺陷，并描述如何与通常部署在Internet上的该规范的实现交互操作。
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
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）机制是一种伪安全机制，使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
SPNEGO机制协商基于以下模型：发起方提出一个安全机制列表，按照递减的优先顺序（首选项优先），接受方（也称为目标方）接受发起方的首选安全机制
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.
机制（列表中的第一个）或从提供的列表中选择一个可用机制；如果两者都不可接受，则接受方拒绝建议值。然后，目标通知发起方其选择。
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\U S\U BAD\U 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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.2.2节所定义）：接受已完成、接受未完成、拒绝或请求mic。拒绝国将终止谈判；accept completed（接受完成）状态表示目标可接受启动器选择的机制，并且嵌入在第一个协商消息中的安全机制令牌足以完成认证；接受未完成状态表示需要进一步的消息交换，但MIC令牌交换（如第5节所述）是可选的；请求mic状态（该状态只能出现在来自目标的第一条回复消息中）表示，如果每条消息的完整性服务可用，则需要进行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.
最后，可以交换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令牌发生冲突，部分建立的上下文不得用于每消息调用。为了保证这一点，从GSS_Init_sec_context（）和GSS_Accept_sec_context（）返回时，prot_ready_状态[RFC2743]必须设置为false，即使底层机制返回true也是如此。
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实现生成一个协商令牌，该令牌包含一个或多个安全机制的列表，这些安全机制基于用于此上下文建立的凭据可用，并且可选地基于列表中第一个机制的初始机制令牌可用。
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.
一） 如果提议的机制均不可接受，则应终止谈判。GSS_Accept_sec_上下文表示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),
二） 如果发起方的首选机制未被目标方接受，或者该机制已被接受但不是接收方的首选机制（即，需要第5节所述的MIC令牌交换），
GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED. The acceptor MUST output a negotiation token containing a request-mic state.
GSS_Accept_sec_context（）表示需要GSS_S_CONTINUE_。接受者必须输出包含请求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.
三） 否则，如果至少需要来自发起方的一个附加协商令牌来建立此上下文，则GSS_Accept_sec_context（）表示需要GSS_S_CONTINUE_，并输出包含接受不完整状态的协商令牌。
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.
四） 否则，不需要发起者提供额外的协商令牌来建立此上下文，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-API约定继续安全上下文初始化，其中所选机制的令牌封装在协商消息中（参见第4节），直到所选安全机制为启动器和目标返回GSS__完成。
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_标志输入参数与所选机制相关，正如*_状态输出参数一样。也就是说，这些参数本身不适用于谈判过程。
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
当为SPNEGO机制获取GSS-API凭据时，实现应为SPNEGO机制生成一个凭据元素，该元素内部包含用于SPNEGO机制的GSS-API凭据元素
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.
主体具有可用凭据的所有机制，但根据实现、站点或特定于应用程序的策略，不需要协商的任何机制除外。有关表示应用程序策略的接口，请参见附录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
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协议消息的编码应遵守ASN.1的可分辨编码规则（DER），如[X690]所述。
In this negotiation model, each OID represents one GSS-API mechanism or one variant (see Section 6) of it, according to [RFC2743].
根据[RFC2743]，在此协商模型中，每个OID代表一个GSS-API机制或其一个变体（见第6节）。
MechType ::= OBJECT IDENTIFIER
-- OID represents each security mechanism as suggested by
-- [RFC2743]
MechType ::= OBJECT IDENTIFIER
-- OID represents each security mechanism as suggested by
-- [RFC2743]
MechTypeList ::= SEQUENCE OF MechType
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
}
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))
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).
此字段包含一个或多个启动器可用的安全机制，按首选项降序排列（首选项优先）。
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
ContextFlags ASN.1类型上的大小约束仅适用于抽象类型。ASN.1 DER要求从抽象定义包含命名位的位字符串类型的编码中截断所有尾随零位。实现应该
not expect to receive exactly 32 bits in an encoding of ContextFlags.
不希望在ContextFlags的编码中正好接收32位。
mechToken
机械令牌
This field, if present, contains the optimistic mechanism token.
此字段（如果存在）包含乐观机制令牌。
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,
...
}
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.
至少需要来自对等方的一条附加协商消息来建立安全上下文。
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.
发送方表示，如果要建立的机制上下文中存在每条消息完整性服务，则需要按照第5节所述交换MIC令牌。该值只能出现在目标公司的第一次回复中。
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
支持技术
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.
该字段只能出现在目标公司的第一次回复中。它必须是启动器提供的机制之一。
ResponseToken
应答器
This field, if present, contains tokens specific to the mechanism selected.
此字段（如果存在）包含特定于所选机制的标记。
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) 通过调用GSS_GetMIC（）在初始协商消息中的机制列表上计算mechlistMIC令牌（或简称为MIC令牌），如下所示：输入上下文_句柄是已建立的机制上下文，输入qop_req是0，输入消息是MechTypeList类型值的DER编码，该值包含在NegTokenInit的“mechTypes”字段。输入消息不是类型“[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_完成但不包括mechlistMIC令牌，或表示需要GSS_S_继续且包括mechlistMIC令牌和接受不完整状态；如果需要MIC令牌交换，则GSS_Accept_sec_context（）表示需要GSS_S_CONTINUE_，并包含mechlistMIC令牌。如附录C所述，希望与旧版Windows SPNEGO实现兼容的接受者不应在不需要MIC令牌交换时生成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.
一） 如果包含mechlistMIC令牌并已正确验证，则GSS_Init_sec_context（）表示GSS_S_完成。输出协商消息包含mechlistMIC令牌和accept_complete状态。然后，接受者必须验证此mechlistMIC令牌。
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令牌但不正确，则应终止协商。GSS_Init_sec_context（）表示GSS_有缺陷的_令牌。
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令牌交换，则GSS_Init_sec_context（）表示GSS_S_已完成，且无输出令牌。
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令牌，则应终止协商。GSS_Accept_sec_context（）表示GSS_有缺陷的_令牌。
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
c) 在所选机制交换奇数个机制令牌的情况下（即，发起方发送最后一个机制令牌），发起方在生成包含最后一个机制令牌的协商消息时执行以下操作：如果在来自目标方的第一次应答中请求mic为negState，必须包含一个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:
令牌是可选的。（请注意，如果选择了启动器首选机制以外的机制，则需要进行MIC令牌交换。）如果乐观机制令牌是启动器首选机制的唯一机制令牌，则mechlistMIC令牌是可选的。无论是否包含mechlistMIC令牌，GSS_Init_sec_context（）表示需要GSS_S_CONTINUE_。如附录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.
一） 如果包含mechlistMIC令牌并已正确验证，则GSS_Accept_sec_context（）表示GSS_S_完成。输出协商消息包含mechlistMIC令牌和accept_complete状态。然后，启动器必须验证此mechlistMIC令牌。
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令牌但不正确，则应终止协商。GSS_Accept_sec_context（）表示GSS_有缺陷的_令牌。
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令牌交换，则GSS_Accept_sec_context（）表示GSS_S_完成。输出协商消息包含接受\完成状态。
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.
四） 如果乐观机制令牌也是最后一个机制令牌（当目标接受启动器的首选机制时），且目标发送请求mic状态，但启动器未发送mechlistMIC令牌，则目标必须在该第一个应答中包含mechlistMIC令牌。GSS_Accept_sec_context（）表示需要GSS_S_CONTINUE_。启动器必须验证收到的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状态（需要交换mic令牌），则应终止协商。GSS_Accept_sec_context（）表示GSS_有缺陷的_令牌。
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.
为扩展性提供了两种机制。首先，本规范中的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.
作者希望感谢Sam Hartman、Nicolas Williams、Ken Raeburn、Martin Rex、Jeff Altman、Tom Yu、Cristian Ilac、Simon Spero和Bill Sommerfeld在本文件编制过程中提出的意见和建议。
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.，“通用安全服务应用程序接口版本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]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
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]
MechType ::= OBJECT IDENTIFIER
-- OID represents each security mechanism as suggested by
-- [RFC2743]
MechTypeList ::= SEQUENCE OF MechType
MechTypeList ::= SEQUENCE OF MechType
NegotiationToken ::= CHOICE {
negTokenInit [0] NegTokenInit,
negTokenResp [1] NegTokenResp
}
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,
...
}
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),
ContextFlags ::= BIT STRING {
delegFlag (0),
mutualFlag (1),
replayFlag (2),
sequenceFlag (3),
anonFlag (4),
confFlag (5), integFlag (6) } (SIZE (32))
confFlag（5）、IntegralFlag（6）}（大小（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调用方（发起方或目标方或两者）提供在一组支持的机制中进行选择的能力，定义了一组简化的协商机制和两个附加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指定默认值--对象标识符的机械集凭证
Outputs:
产出：
o major_status INTEGER, o minor_status INTEGER
o 主\u状态整数，o次\u状态整数
Return major_status codes:
返回主要_状态代码：
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_故障表示由于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
这允许调用者指定一组可以与cred_handle标识的凭证协商的安全机制。此调用旨在支持需要从调用方可用的所有安全机制集中限制可协商安全机制集的专用调用方（基于可用的
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.
证书）。请注意，如果在mech_集合中指定了多个机构，则指定这些机构的顺序意味着相对偏好。
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 对象标识符的主要\ U状态整数、o次要\ U状态整数、o机械\ U集
Return major_status codes:
返回主要_状态代码：
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_故障表示由于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，也不处理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中的MechType不是可选的。
* 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.
如果两个对等方中至少有一个实现了本文档中更新的伪机制，则协商将受到保护。
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.
* 交换两个麦克风令牌，每个方向一个。
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正确实现的兼容性。
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”是长度编码，可能长于一个八位字节）：
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 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 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}
-- 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节中的规则），则可以使用启动器的NegTokenInit令牌中MechTypeList类型数据的DER编码作为GSS_GetMIC（）函数的输入来计算它。在这种情况下，将通过以下八位字节计算MIC：
DER encoding of MechTypeList: 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...
机械类型列表的顺序编码：30 nn 06 09 2A 86 48 86 F7 12 01 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微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: lzhu@microsoft.com
EMail: lzhu@microsoft.com
Paul Leach Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Paul Leach微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: paulle@microsoft.com
EMail: paulle@microsoft.com
Karthik Jaganathan Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Karthik Jaganathan微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: karthikj@microsoft.com
EMail: karthikj@microsoft.com
Wyllys Ingersoll Sun Microsystems 1775 Wiehle Avenue, 2nd Floor Reston, VA 20190 US
美国弗吉尼亚州莱斯顿维尔大道1775号威利英格索尔太阳微系统公司，二楼，邮编：20190
EMail: wyllys.ingersoll@sun.com
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。