Network Working Group E. Baize
Request for Comments: 2478 D. Pinkas
Category: Standards Track Bull
December 1998
Network Working Group E. Baize
Request for Comments: 2478 D. Pinkas
Category: Standards Track Bull
December 1998
The Simple and Protected 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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in [1].
本文件规定了通用安全服务应用程序接口（GSS-API）的安全协商机制，如[1]所述。
The GSS-API provides a generic interface which 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 doesn't prescribe the method by which GSS-API peers can establish whether they have a common security mechanism.
GSS-API提供了一个通用接口，该接口可以分层在不同的安全机制之上，这样，如果通信对等方获取相同安全机制的GSS-API凭据，则可以在它们之间建立安全上下文（取决于策略）。然而，GSS-API并没有规定GSS-API对等方可以通过什么方法来确定它们是否具有共同的安全机制。
The Simple and Protected GSS-API Negotiation Mechanism defined here is a pseudo-security mechanism, represented by the object identifier iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which enables GSS-API peers to determine in-band whether their credentials share common GSS-API security mechanism(s), and if so, to invoke normal security context establishment for a selected common security mechanism. This is most useful for applications that are based on GSS-API implementations which support multiple security mechanisms.
此处定义的简单且受保护的GSS-API协商机制是一种伪安全机制，由对象标识符iso.org.dod.internet.security.Mechanism.snego（1.3.6.1.5.5.2）表示，它使GSS-API对等方能够确定其凭证是否共享通用GSS-API安全机制，如果共享，调用所选公共安全机制的正常安全上下文建立。这对于基于支持多种安全机制的GSS-API实现的应用程序非常有用。
This allows to negotiate different security mechanisms, different options within a given security mechanism or different options from several security mechanisms.
这允许协商不同的安全机制、给定安全机制中的不同选项或多个安全机制中的不同选项。
Once the common security mechanism is identified, the security mechanism may also negotiate mechanism-specific options during its context establishment. This will be inside the mechanism tokens, and invisible to the SPNEGO protocol.
一旦确定了共同安全机制，安全机制还可以在其上下文建立期间协商机制特定的选项。这将位于机制令牌内，并且对SPNEGO协议不可见。
The simple and protected GSS-API mechanism negotiation is based on the following negotiation model : the initiator proposes one security mechanism or an ordered list of security mechanisms, the target either accepts the proposed security mechanism, or chooses one from an offered set, or rejects the proposed value(s). The target then informs the initiator of its choice.
简单且受保护的GSS-API机制协商基于以下协商模型：发起方提出一种安全机制或安全机制的有序列表，目标方接受建议的安全机制，或从提供的集合中选择一种，或拒绝建议的值。然后，目标通知发起方其选择。
In its basic form this protocol requires an extra-round trip. Network connection setup is a critical performance characteristic of any network infrastructure and extra round trips over WAN links, packet radio networks, etc. really make a difference. In order to avoid such an extra round trip the initial security token of the preferred mechanism for the initiator may be embedded in the initial token. If the target preferred mechanism matches the initiator's preferred mechanism, no additional round trips are incurred by using the negotiation protocol.
在其基本形式中，该协议需要额外的往返行程。网络连接设置是任何网络基础设施的关键性能特征，通过WAN链路、分组无线网络等进行额外的往返确实会产生影响。为了避免这种额外的往返，可以在初始令牌中嵌入启动器的优选机制的初始安全令牌。如果目标首选机制与启动器的首选机制匹配，则使用协商协议不会产生额外的往返。
The simple and protected GSS-API mechanism negotiation provides a technique to protect the negotiation that must be used when the underlying mechanism selected by the target is capable of integrity protection.
简单且受保护的GSS-API机制协商提供了一种保护协商的技术，当目标选择的底层机制能够进行完整性保护时，必须使用这种技术。
When all the mechanisms proposed by the initiator support integrity protection or when the selected mechanism supports integrity protection, then the negotiation mechanism becomes protected since this guarantees that the appropriate mechanism supported by both peers has been selected.
当发起方提出的所有机制都支持完整性保护时，或者当所选机制支持完整性保护时，协商机制将受到保护，因为这保证了已选择两个对等方支持的适当机制。
The Simple and Protected GSS-API Negotiation Mechanism uses the concepts developed in the GSS-API specification [1]. 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.
简单且受保护的GSS-API协商机制使用GSS-API规范[1]中开发的概念。协商数据封装在上下文级令牌中。因此，GSS-API的调用方不需要知道协商令牌的存在，而只需要知道新的伪安全机制。协商阶段的失败导致返回一个主要状态代码：GSS\U S\U BAD\U MECH。
The model for security mechanism negotiation reuses a subset of the concepts specified in [2].
安全机制协商模型重用了[2]中指定的概念子集。
Each OID represents one GSS-API mechanism or one variant of it.
每个OID代表一个GSS-API机制或其一个变体。
- When one security mechanism is proposed by the initiator, it represents the only security mechanism supported or selected (when the additional APIs defined in the Annex A are used) by the initiator.
- 当发起人提出一种安全机制时，它代表发起人支持或选择的唯一安全机制（当使用附录A中定义的附加API时）。
- When several security mechanisms are proposed by the initiator, they represent a set of security mechanisms supported or selected (when the additional APIs defined in the Annex A are used) by the initiator.
- 当发起人提出多个安全机制时，它们代表发起人支持或选择的一组安全机制（当使用附录a中定义的附加API时）。
The first negotiation token sent by the initiator contains an ordered list of mechanisms, a set of options (e.g. deleg, replay, conf flags) that should be supported by the selected mechanism and optionally the initial security token for the desired mechanism of the initiator (i.e. the first of the list).
发起者发送的第一个协商令牌包含一个有序的机制列表、一组选项（如deleg、RELAY、conf标志），所选机制应支持这些选项，还可以选择发起者所需机制的初始安全令牌（即列表中的第一个）。
The first negotiation token sent by the target contains the result of the negotiation (accept_completed, accept_incomplete or reject) and, in case of accept, the agreed security mechanism. It may also include the response to the initial security token from the initiator, when the first proposed mechanism of the initiator has been selected. When the first mechanism is acceptable to the target,it should respond to the initial security token for the desired mechanism of the initiator when it is present. However, if this is not possible, the target can simply ignore it and omit the responseToken from the first reply.
目标发送的第一个协商令牌包含协商结果（accept_completed、accept_Complete或reject），如果是accept，则包含约定的安全机制。它还可以包括当选择了发起方的第一个提议的机制时，对来自发起方的初始安全令牌的响应。当目标可以接受第一种机制时，它应该在存在启动器所需机制时响应该机制的初始安全令牌。但是，如果这是不可能的，目标可以简单地忽略它，并从第一个回复中省略responseToken。
Implementations that can piggyback the initial token will be rewarded by faster connection setup.
可以搭载初始令牌的实现将通过更快的连接设置获得回报。
In case of a successful negotiation, the security mechanism represents the value suitable for the target, and picked up from the list offered by the initiator. The policy by which the target chooses a mechanism is an implementation-specific local matter. In the absence of other policy, the target should chose the first mechanism in the list for which valid credentials are available.
在协商成功的情况下，安全机制表示适合目标的值，并从发起方提供的列表中选取。目标选择机制所依据的政策是特定于实施的本地事务。在没有其他策略的情况下，目标应选择列表中第一个有效凭据可用的机制。
Once a mechanism has been selected, the tokens specific to the selected mechanism are carried within the negotiation tokens (in the mechToken for the initiator and in the responseToken for the target).
一旦选择了一个机制，特定于所选机制的令牌将携带在协商令牌中（在启动器的mechToken和目标的responseToken中）。
The negotiation procedure is summarised as follows:
谈判程序总结如下：
(a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but requests (either explicitly, with the negotiation mechanism, or through accepting a default, when the default is the negotiation mechanism) that the Simple and Protected GSS-API Negotiation Mechanism be used;
(a) GSS-API启动器正常调用GSS_Init_sec_上下文，但请求（明确地，通过协商机制，或通过接受默认，当默认为协商机制时）使用简单且受保护的GSS-API协商机制；
(b) the initiator GSS-API implementation emits a negotiation token containing a list of supported security mechanisms for the credentials used for this context establishment, and optionally an initial security token for the first mechanism from that list (i.e. the preferred mechanism), and indicates GSS_S_CONTINUE_NEEDED status;
(b) 发起方GSS-API实现发出一个协商令牌，该令牌包含用于此上下文建立的凭据的受支持安全机制列表，以及可选地来自该列表的第一个机制（即首选机制）的初始安全令牌，并指示GSS_S_CONTINUE_Required状态；
(c) The GSS-API initiator sends the token to the target application;
(c) GSS-API发起方向目标应用发送令牌；
(d) The GSS-API target deposits the token through invoking GSS_Accept_sec_context. The target GSS-API implementation emits a negotiation token containing which if any of the proposed mechanisms it supports (or has selected).
(d) GSS-API目标通过调用GSS_Accept_sec_上下文来存放令牌。目标GSS-API实现发出一个协商令牌，其中包含它支持（或已选择）的任何建议机制。
If the mechanism selected by the target matches the preferred mechanism identified by the initiator and the initiator provides a mechToken, the negotiation token response may contain also an initial security token from that mechanism.
如果目标选择的机制与启动器标识的首选机制匹配，并且启动器提供mechToken，则协商令牌响应还可以包含来自该机制的初始安全令牌。
If the preferred mechanism is accepted, GSS_Accept_sec_context() indicates GSS_S_COMPLETE when unilateral or mutual authentication has been performed and involves a single token in either direction.
如果接受首选机制，则GSS_Accept_sec_context（）在执行单边或相互身份验证时表示GSS_S_已完成，并在任一方向涉及单个令牌。
If a proposed mechanism is accepted, and it was not the preferred mechanism, or if the first negotiation token sent by the initiator did not included a mechToken, then the negotiation token response sent by the target may contain also a response token from that mechanism which transmits mechanism-specific information (e.g. to transmit a certificate). The initiator may ignore such an initial token if it is not prepared to process it.
如果提议的机制被接受，并且它不是首选机制，或者如果发起方发送的第一个协商令牌不包括mechToken，则目标方发送的协商令牌响应还可以包含来自该机制的响应令牌，该机制发送机制特定信息（例如传输证书）。如果发起者不准备处理初始令牌，则发起者可以忽略该初始令牌。
If a proposed mechanism other than the preferred mechanism is accepted, or the preferred mechanism is accepted but involves multiple exchanges (e.g. challenge-response authentication), then GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED status.
如果接受了首选机制以外的建议机制，或者接受了首选机制但涉及多个交换（例如，质询-响应身份验证），则GSS_接受_sec_context（）表示GSS_继续_需要的状态。
If the proposed mechanism(s) are rejected, GSS_Accept_sec_context() indicates GSS_S_BAD_MECH status. The security context initialisation has failed.
如果建议的机制被拒绝，则GSS_Accept_sec_context（）表示GSS_s_BAD_MECH状态。安全上下文初始化失败。
(e) The GSS-API target returns the token to the initiator application;
(e) GSS-API目标将令牌返回给发起方应用程序；
(f) The GSS-API initiator deposits the token through invoking GSS_Init_sec_context.
(f) GSS-API启动器通过调用GSS_Init_sec_上下文来存放令牌。
GSS_Init_sec_context() may then indicate GSS_S_CONTINUE_NEEDED, GSS_S_COMPLETE or GSS_S_BAD_MECH status.
然后，GSS_Init_sec_context（）可能表示需要GSS_S_CONTINUE_、GSS_S_COMPLETE或GSS_BAD_MECH状态。
The GSS_S_BAD_MECH status is returned when the negotiation token carries a reject result or when the negotiation token carries an accept result and the mechanism selected by the target is not included in the initial list sent by the initiator.
当协商令牌携带拒绝结果或当协商令牌携带接受结果且目标选择的机制不包括在发起方发送的初始列表中时，返回GSS_S_BAD_MECH状态。
The GSS_S_BAD_MIC status is returned when the selected mechanism supports a MIC token but the MIC computed over the list of mechanisms sent by the initiator is missing or incorrect.
当所选机制支持MIC令牌，但通过启动器发送的机制列表计算的MIC丢失或不正确时，将返回GSS_S_BAD_MIC状态。
If the negotiation token carries a reject result, the context establishment is impossible. For example, a rejection will occur if the target doesn't support the initiator's proposed mechanism type(s). Upon failure of the mechanism negotiation procedure, the mech_type output parameter value is the negotiation mechanism type.
如果协商令牌携带拒绝结果，则无法建立上下文。例如，如果目标不支持启动器建议的机制类型，将发生拒绝。机制协商程序失败时，mech_类型输出参数值为协商机制类型。
The GSS_S_CONTINUE_NEEDED status is returned when the negotiation token carries an accept result and further tokens must be transferred in order to complete context establishment for the selected mechanism. In that case GSS_Init_sec_context() returns an initial context token as output_token (with the selected mechanism's context token encapsulated within that output_token).
当协商令牌携带接受结果时，返回GSS_S_CONTINUE_Required状态，并且必须传输更多令牌才能完成所选机制的上下文建立。在这种情况下，GSS_Init_sec_context（）返回一个初始上下文标记作为输出_标记（所选机制的上下文标记封装在该输出_标记中）。
The initiator then sends the output_token to the target. The security context initialisation is then continued according to the standard GSS-API conventions for the selected mechanism, where the tokens of the selected mechanism are encapsulated until the GSS_S_COMPLETE is returned for both the initiator and the target. When GSS_S_CONTINUE_NEEDED is returned, the mech_type output parameter is not yet valid.
然后，启动器将输出令牌发送到目标。然后根据所选机制的标准GSS-API约定继续安全上下文初始化，其中所选机制的令牌被封装，直到为启动器和目标返回GSS__完成。当返回所需的GSS_S_CONTINUE_时，mech_类型输出参数无效。
When GSS_S_COMPLETE is returned, the mech_type output parameter indicates the selected mechanism. When the final negotiation token does not contain a MIC, the initiator GSS-API implementation must check the returned/selected mechanism is on the originally
当返回GSS_S_COMPLETE时，mech_类型输出参数指示所选机构。当最终协商令牌不包含MIC时，发起方GSS-API实现必须检查返回/选择的机制是否处于初始状态
submitted list of mechanisms and also verify that the selected mechanism is not able to support a MIC. When the final negotiation token contains a MIC over the initial mechanisms list sent by the initiator, the MIC must be verified.
已提交机制列表，并验证所选机制无法支持MIC。当最终协商令牌包含启动器发送的初始机制列表上的MIC时，必须验证MIC。
Note that the *_req_flag input parameters for context establishment are relative to the selected mechanism, as are the *_state output parameters. i.e., these parameters are not applicable to the negotiation process per se.
请注意，用于上下文建立的*_req_标志输入参数与所选机制相关，正如*_状态输出参数一样。i、 例如，这些参数本身不适用于谈判过程。
The initiator GSS-API calling application may need to know when the negotiation exchanges were protected or not. For this, when GSS_S_COMPLETE is returned, it can simply test the integ_avail flag. When this flag is set it indicates that the negotiation was protected.
发起方GSS-API调用应用程序可能需要知道协商交换何时受到保护。为此，当返回GSS_S_COMPLETE时，它可以简单地测试integ_avail标志。设置此标志时，表示协商受到保护。
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 if a particular basic security mechanism had been requested but was not supported.
在目标端接收到协商令牌时，不支持协商的GSS-API实现将指示GSS_S_BAD_MECH状态，就好像请求了特定的基本安全机制，但不受支持一样。
When GSS_Acquire_cred is invoked with the negotiation mechanism as desired_mechs, an implementation-specific default credential is used to carry on the negotiation. A set of mechanisms as specified locally by the system administrator is then available for negotiation. If there is a desire for the caller to make its own choice, then an additional API has to be used (see Appendix A).
当使用协商机制调用GSS_Acquire_cred作为所需的协商机制时，将使用特定于实现的默认凭证来进行协商。系统管理员在本地指定的一组机制可用于协商。如果调用方希望做出自己的选择，则必须使用额外的API（参见附录a）。
MechType::= OBJECT IDENTIFIER
MechType::= OBJECT IDENTIFIER
mechType Each security mechanism is as defined in [1].
每个安全机制的定义见[1]。
The syntax of the negotiation tokens follows the InitialContextToken syntax defined in [1]. The security mechanism of the initial negotiation token is identified by the Object Identifier iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).
协商令牌的语法遵循[1]中定义的InitialContextToken语法。初始协商令牌的安全机制由对象标识符iso.org.dod.internet.security.mechanism.snego（1.3.6.1.5.5.2）标识。
This section specifies the syntax of the corresponding "innerContextToken" field for the first token and subsequent negotiation tokens. During the mechanism negociation, the "innerContextToken" field contains the ASN.1 structure "NegociationToken" given below, encoded using the DER encoding conventions.
本节指定第一个令牌和后续协商令牌对应的“innerContextToken”字段的语法。在机制协商期间，“innerContextToken”字段包含下面给出的ASN.1结构“NegoationToken”，使用DER编码约定进行编码。
NegotiationToken ::= CHOICE {
negTokenInit [0] NegTokenInit,
negTokenTarg [1] NegTokenTarg }
NegotiationToken ::= CHOICE {
negTokenInit [0] NegTokenInit,
negTokenTarg [1] NegTokenTarg }
MechTypeList ::= SEQUENCE OF MechType
MechTypeList ::= SEQUENCE OF MechType
NegTokenInit ::= SEQUENCE {
mechTypes [0] MechTypeList OPTIONAL,
reqFlags [1] ContextFlags OPTIONAL,
mechToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL
}
NegTokenInit ::= SEQUENCE {
mechTypes [0] MechTypeList OPTIONAL,
reqFlags [1] ContextFlags OPTIONAL,
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)
}
ContextFlags ::= BIT STRING {
delegFlag (0),
mutualFlag (1),
replayFlag (2),
sequenceFlag (3),
anonFlag (4),
confFlag (5),
integFlag (6)
}
negTokenInit Negotiation token sent by the initiator to the target, which contains, for the first token sent, one or more security mechanisms supported by the initiator (as indicated in the field mechTypes) and the service options (reqFlags) that are requested to establish the context. The context flags should be filled in from the req_flags parameter of init_sec_context().
发起程序发送到目标的negTokenInit协商令牌，对于发送的第一个令牌，它包含发起程序支持的一个或多个安全机制（如字段mechTypes中所示）以及为建立上下文而请求的服务选项（reqFlags）。应该从init_sec_context（）的req_flags参数中填写上下文标志。
The mechToken field is optional for the first token sent that all target implementations would not have to support. However for those targets that do support piggybacking the initial mechToken, an optimistic negotiation response is possible. Otherwise the mechToken is used to carry the tokens specific to the mechanism selected.
mechToken字段对于发送的所有目标实现都不必支持的第一个令牌是可选的。然而，对于那些确实支持搭载初始mechToken的目标，乐观的协商响应是可能的。否则，mechToken用于携带特定于所选机制的令牌。
The mechListMIC is an optional field. In the case that the chosen mechanism supports integrity, the initiator may optionally include a mechListMIC which is the result of a GetMIC of the MechTypes in the initial NegTokenInit and return GSS_S_COMPLETE.
mechListMIC是可选字段。在所选机制支持完整性的情况下，启动器可以选择性地包括mechListMIC，该mechListMIC是初始NegTokenInit中MechType的GetMIC的结果，并返回GSS_S_COMPLETE。
When the chosen mechanism uses an odd number of messages, the final mechanism token will be sent from the initiator to the acceptor. In this case, there is a tradeoff between using the optimal number of messages, or using an additional message from the acceptor to the initiator in order to give the initiator assurance that no modification of the initiator's mechanism list occurred. The implementation can choose which tradeoff to make (see section 4.2.2 for further details for the processing of that field).
当所选机制使用奇数条消息时，最终的机制令牌将从启动器发送到接收方。在这种情况下，在使用最佳消息数量，或使用从接受者到发起方的附加消息，以便向发起方保证不会修改发起方的机制列表之间存在折衷。实现可以选择进行折衷（有关该字段处理的更多详细信息，请参阅第4.2.2节）。
NegTokenTarg ::= SEQUENCE {
negResult [0] ENUMERATED {
accept_completed (0),
accept_incomplete (1),
reject (2) } OPTIONAL,
supportedMech [1] MechType OPTIONAL,
responseToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL
}
NegTokenTarg ::= SEQUENCE {
negResult [0] ENUMERATED {
accept_completed (0),
accept_incomplete (1),
reject (2) } OPTIONAL,
supportedMech [1] MechType OPTIONAL,
responseToken [2] OCTET STRING OPTIONAL,
mechListMIC [3] OCTET STRING OPTIONAL
}
negTokenTarg Negotiation token returned by the target to the initiator which contains, for the first token returned, a global negotiation result and the security mechanism selected (if any).
目标向发起方返回的negTokenTarg协商令牌，对于返回的第一个令牌，该令牌包含全局协商结果和选择的安全机制（如果有）。
negResult The result accept_completed indicates that a context has been successfully established, while the result accept_incomplete indicates that additional token exchanges are needed.
Negersult结果accept_completed表示上下文已成功建立，而结果accept_Complete表示需要额外的令牌交换。
Note: For the case where (a) a single-token context setup is used and (b) the preferred mechanism does not support the integrity facility which would cause a mechListMIC to be generated and enclosed, this feature allows to make a difference between a mechToken sent by the initiator but not processed by the target (accept_incomplete) and a mechToken sent by the initiator and processed by the target (accept_completed).
注意：对于（a）使用单个令牌上下文设置和（b）首选机制不支持完整性设施（这将导致生成和封装mechListMIC）的情况，此功能允许在启动器发送但目标未处理的mechToken之间进行区分（accept_Complete）以及由发起方发送并由目标方处理的令牌（accept_completed）。
For those targets that support piggybacking the initial mechToken, an optimistic negotiation response is possible and includes in that case a responseToken which may continue the authentication exchange (e.g. when mutual authentication has been requested or when unilateral authentication requires several round trips). Otherwise
对于支持搭载初始mechToken的那些目标，乐观协商响应是可能的，并且在这种情况下包括一个responseToken，该responseToken可以继续身份验证交换（例如，当请求相互身份验证时，或者当单边身份验证需要多次往返时）。否则
the responseToken is used to carry the tokens specific to the mechanism selected. For subsequent tokens (if any) returned by the target, negResult, and supportedMech are not present.
responseToken用于携带特定于所选机制的令牌。对于目标返回的后续令牌（如果有），Negersult和supportedMech不存在。
For the last token returned by the target, the mechListMIC, when present, is a MIC computed over the MechTypes using the selected mechanism.
对于目标返回的最后一个令牌，mechListMIC（当存在时）是使用所选机制在MechTypes上计算的MIC。
negResult Result of the negotiation exchange, specified by the target.
目标指定的协商交换的negResult结果。
This can be either :
这可以是：
accept_completed The target accepts the preferred security mechanism, and the context is established for the target or,
accept_completed目标接受首选安全机制，并为目标建立上下文，或，
accept_incomplete The target accepts one of the proposed security mechanisms and further exchanges are necessary, or,
accept_Complete目标公司接受其中一个提议的安全机制，并且需要进一步交换，或者，
reject The target rejects all the proposed security mechanisms.
拒绝目标拒绝所有建议的安全机制。
supportedMech This field has to be present when negResult is "accept_completed" or "accept_incomplete". It is a choice from the mechanisms offered by the initiator.
supportedMech当NegerResult为“accept_completed”或“accept_Complete”时，此字段必须存在。它是从启动器提供的机制中选择的。
responseToken This field may be used either to transmit the response to the mechToken when sent by the initiator and when the first mechanism from the list has been selected by the target or to carry the tokens specific to the selected security mechanism.
responseToken此字段可用于在启动器发送响应时以及目标选择列表中的第一个机制时，将响应发送到mechToken，或用于携带特定于所选安全机制的令牌。
mechListMIC If the selected mechanism is capable of integrity protection, this field must be present in the last message of the negotiation, (i.e., when the underlying mechanism returns a non-empty token and a major status of GSS_S_COMPLETE); it contains the result of a GetMIC of the MechTypes field in the initial NegTokenInit. It allows to verify that the list initially sent by the initiator has been received unmodified by the target.
mechListMIC如果所选机制能够进行完整性保护，则该字段必须出现在协商的最后一条消息中（即，当基础机制返回非空令牌和GSS__完成的主要状态时）；它包含初始NegTokenInit中MechTypes字段的GetMIC结果。它允许验证发起方最初发送的列表是否已被目标方未经修改地接收到。
3.2.2. Processing of mechListMIC.
3.2.2. 机械加工。
If the mechanism selected by the negotiation does not support integrity, then no mechListMIC is included, otherwise a mechListMIC must be used and validated as indicated below.
如果协商选择的机制不支持完整性，则不包括mechListMIC，否则必须使用mechListMIC并进行验证，如下所示。
If the mechanism supports integrity and uses an even number of messages, then the target must compute a MIC as described above, and send this in the final NegTokenTarg along with the final mechToken. The initiator when receiving the last token must require that the mechListMIC field be present and valid. In the absence of a valid mechListMIC, the negotiation must fail as if the last context establishment token was invalid.
如果该机制支持完整性并使用偶数条消息，则目标必须如上所述计算MIC，并将其与最终mechToken一起发送到最终NegTokenTarg中。启动器在接收最后一个令牌时必须要求mechListMIC字段存在且有效。如果没有有效的mechListMIC，协商必须失败，就像最后一个上下文建立令牌无效一样。
In the case that the chosen mechanism supports integrity and uses an odd number of messages, the final mechanism token will be sent from the initiator to the target. In this case, there is a tradeoff between using the optimal number of messages, or using an additional message from the target to the initiator in order to give the initiator assurance that no modification of the initiator's mechanism list occurred. The implementation can choose which tradeoff to make.
如果所选机制支持完整性并使用奇数条消息，则最终机制令牌将从启动器发送到目标。在这种情况下，在使用最佳消息数或使用从目标到启动器的附加消息之间存在折衷，以便向启动器保证不会修改启动器的机制列表。实现可以选择进行哪种权衡。
When generating the final NegTokenInit message, the NegTokenInit may optionally include a mechListMIC which is the result of a GetMIC of the MechTypes in the initial NegTokenInit and return GSS_S_COMPLETE. The target must check the presence of the MIC computed over the mechList sent in the initial NegTokenInit. Three cases may then be considered:
当生成最终的NegTokenInit消息时，NegTokenInit可以选择性地包括mechListMIC，该mechListMIC是初始NegTokenInit中MechType的GetMIC的结果，并返回GSS_S_COMPLETE。目标必须检查通过初始NegTokenInit中发送的mechList计算的MIC是否存在。然后可考虑三种情况：
1) If the mechListMIC is present and correct, then GSS_S_COMPLETE is returned to the target with no token; the context is established by the target.
1) 如果mechListMIC存在且正确，则GSS_S_COMPLETE将返回到目标，而不带令牌；上下文由目标建立。
2) If the mechListMIC is present but invalid, then the context establishment must fail. An error major status code is returned to the target.
2) 如果mechListMIC存在但无效，则上下文建立必须失败。将错误主要状态代码返回给目标。
3) If the mechListMIC is not included in the final NegTokenInit, then GSS_S_COMPLETE must be returned to the target with a token. This token must be a NegTokenTarg, with a MIC included as described above, and no responseToken. The application will then send this token back to the initiator, which must verify that the mechListMIC field is present and valid.
3) 如果mechListMIC未包含在最终的NegTokenInit中，则必须使用令牌将GSS_S_COMPLETE返回给目标。此令牌必须是NegTokenTarg，如上所述包含麦克风，且无响应。然后，应用程序将此令牌发送回启动器，启动器必须验证mechListMIC字段是否存在且有效。
Note: If the MIC was originally sent by the initiator, but thenafter deleted by an attacker, the target will send back a token according to the description above, but the initiator will be unable to process that returned token and the context establishment must then fail.
注意：如果MIC最初由启动器发送，但在被攻击者删除后，目标将根据上述描述发回令牌，但启动器将无法处理返回的令牌，因此上下文建立必须失败。
Here are some examples of security mechanism negotiation between an initiator (I) and a target (T).
以下是启动器（I）和目标（T）之间安全机制协商的一些示例。
(I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
（一） 支持两种安全机制类型（GSS-MECH1和GSS-MECH2）。
(I) invokes GSS_Init_sec_context() with :
（一） 使用以下命令调用GSS_Init_sec_context（）：
Input mech_type = OID for negotiation mechanism or NULL, if the negotiation mechanism is the default mechanism.
Input mech_type=协商机制的OID或NULL（如果协商机制是默认机制）。
Output major_status = GSS_S_CONTINUE_NEEDED output_token = negTokenInit
输出主要\u状态=GSS\U S\u继续\u需要的输出\u令牌=negTokenInit
The negotiation token (negTokenInit) contains two security mechanisms with : mechType = GSS-MECH1 or mechType = GSS-MECH2
协商令牌（negTokenInit）包含两种安全机制：mechType=GSS-MECH1或mechType=GSS-MECH2
(I) sends to (T) the negotiation token.
（一） 向（T）发送协商令牌。
(T) supports GSS-MECH2 (T) receives the negotiation token (negTokenInit) from (I) (T) invokes GSS_Accept_sec_context() with :
（T） 支持GSS-MECH2（T）从（I）（T）接收协商令牌（negTokenInit）调用GSS_Accept_secu_context（），方法是：
Input input_token = negTokenInit
输入\u令牌=negTokenInit
Output major_status = GSS_S_CONTINUE_NEEDED output_token = negTokenTarg
输出主要\u状态=GSS\U S\u继续\u需要的输出\u令牌=负令牌目标
The negotiation token (negTokenTarg) contains : negResult = accept (the negotiation result) supportedMech : mechType = GSS-MECH2
协商令牌（negTokenTarg）包含：negResult=accept（协商结果）supportedMech:mechType=GSS-MECH2
(T) returns the negotiation token (negTokenTarg) to (I) (I) invokes GSS_Init_sec_context() with :
（T） 将协商令牌（negTokenTarg）返回到（I）（I）调用GSS_Init_sec_context（），方法是：
Input input_token = negTokenTarg
输入\u令牌=negTokenTarg
Output major_status = GSS_S_COMPLETE output_token = initialContextToken (initial context token for GSS-MECH2) mech_type = GSS-MECH2
输出主要\u状态=GSS\U S\u完成输出\u令牌=初始上下文令牌（GSS-MECH2的初始上下文令牌）机械类型=GSS-MECH2
The subsequent steps are security mechanism specific, and work as specified in [1]. The output tokens from the security mechanism are encapsulated in a NegTokenTarg message (with the supportedMech field omitted, and the mechListMIC included with the last token).
后续步骤是特定于安全机制的，并按照[1]中的规定工作。安全机制的输出令牌封装在NegTokenTarg消息中（省略supportedMech字段，最后一个令牌包含mechListMIC）。
(T) supports GSS-MECH3. (T) receives the negotiation token (negTokenInit) from (I) (T) invokes GSS_Accept_sec_context() with :
（T） 支持GSS-MECH3。（T） 从（I）（T）接收协商令牌（negTokenInit）调用GSS_Accept_sec_context（），方法是：
Input input_token = negTokenInit
输入\u令牌=negTokenInit
Output major_status = GSS_S_BAD_MECH output_token = negTokenTarg
输出主要\u状态=GSS\u S\u坏\u机械输出\u令牌=负令牌目标
The negotiation token (negTokenTarg) contains :
协商令牌（negTokenTarg）包含：
negResult = reject (the negotiation result)
Negersult=拒绝（谈判结果）
(T) returns the negotiation token (negTokenTarg) to (I) (I) invokes GSS_Init_sec_context() with :
（T） 将协商令牌（negTokenTarg）返回到（I）（I）调用GSS_Init_sec_context（），方法是：
Input input_token = negTokenTarg
输入\u令牌=negTokenTarg
Output major_status = GSS_S_BAD_MECH
输出主要机械状态=GSS\U S\U坏机械
The security context establishment has failed.
安全上下文建立失败。
(I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
（一） 支持两种安全机制类型（GSS-MECH1和GSS-MECH2）。
(I) invokes GSS_Init_sec_context() with :
（一） 使用以下命令调用GSS_Init_sec_context（）：
Input mech_type = OID for negotiation mechanism or NULL, if the negotiation mechanism is the default mechanism.
Input mech_type=协商机制的OID或NULL（如果协商机制是默认机制）。
Output major_status = GSS_S_CONTINUE_NEEDED output_token = negTokenInit
输出主要\u状态=GSS\U S\u继续\u需要的输出\u令牌=negTokenInit
The negotiation token (negTokenInit) contains two security mechanisms with : mechType = GSS-MECH1 or mechType = GSS-MECH2
协商令牌（negTokenInit）包含两种安全机制：mechType=GSS-MECH1或mechType=GSS-MECH2
mechToken = output_token from GSS_Init_sec_context ( first mechType) as described in [1]
mechToken=GSS_Init_sec_上下文（第一个mechType）的输出_令牌，如[1]所述
(I) sends to (T) the negotiation token.
（一） 向（T）发送协商令牌。
(T) supports GSS-MECH1. (T) receives the negotiation token (negTokenInit) from (I) (T) invokes GSS_Accept_sec_context() with :
（T） 支持GSS-MECH1。（T） 从（I）（T）接收协商令牌（negTokenInit）调用GSS_Accept_sec_context（），方法是：
Input input_token = negTokenInit
输入\u令牌=negTokenInit
Output major_status = GSS_S_CONTINUE_NEEDED output_token = negTokenTarg
输出主要\u状态=GSS\U S\u继续\u需要的输出\u令牌=负令牌目标
The negotiation token (negTokenTarg) contains : negResult = accept (the negotiation result) supportedMech : mechType = GSS-MECH1
协商令牌（negTokenTarg）包含：negResult=accept（协商结果）supportedMech:mechType=GSS-MECH1
mechToken = output_token from GSS_Accept_sec_context(mechToken )
mechToken=GSS_Accept_sec_上下文中的输出_令牌（mechToken）
(T) returns the negotiation token (negTokenTarg) to (I) (I) invokes GSS_Init_sec_context() with :
（T） 将协商令牌（negTokenTarg）返回到（I）（I）调用GSS_Init_sec_context（），方法是：
Input input_token = negTokenTarg
输入\u令牌=negTokenTarg
Output major_status = GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED as needed output_token = ContextToken (initial or subsequent context token for GSS-MECH1) mech_type = GSS-MECH1
输出主要\ U状态=GSS\ U S\ U完成或GSS\ U继续\根据需要输出\ U标记=上下文标记（GSS-MECH1的初始或后续上下文标记）机械类型=GSS-MECH1
Specific implementations of the protocol can support the optimistic negotiation by completing the security context establishment using the agreed upon mechanism as described in [1]. As described above in section 5.2, the output tokens from the security mechanisms are encapsulated in a NegTokenTarg message (with the negResult and supportedMech fields omitted, and the mechListMIC included with the last token).
协议的具体实现可以通过使用[1]中所述的商定机制完成安全上下文的建立来支持乐观协商。如上文第5.2节所述，安全机制的输出令牌封装在NegTokenTarg消息中（省略NegerSult和supportedMech字段，最后一个令牌包含mechListMIC）。
When the mechanism selected by the target from the list supplied by the initiator supports integrity protection, then the negotiation is protected.
当目标从启动器提供的列表中选择的机制支持完整性保护时，协商将受到保护。
When one of the mechanisms proposed by the initiator does not support integrity protection, then the negotiation is exposed to all threats a non secured service is exposed. In particular, an active attacker can force to use a security mechanism which is not the common preferred one (when multiple security mechanisms are shared between peers) but which is acceptable anyway to the target.
当发起方提出的机制之一不支持完整性保护时，协商将暴露于所有威胁，而非安全服务将暴露。特别是，主动攻击者可以强制使用一种安全机制，该机制不是常见的首选机制（当对等方之间共享多个安全机制时），但无论如何目标都可以接受。
In any case, the communicating peers may be exposed to the denial of service threat.
在任何情况下，通信对等方都可能面临拒绝服务威胁。
Acknowledgments are due to Stephen Farrell of SSE, Marc Horowitz of Stonecast, John Linn of RSA Laboratories, Piers McMahon of Platinum Technology, Tom Parker of ICL and Doug Rosenthal of EINet, for reviewing earlier versions of this document and for providing useful inputs. Acknowledgments are also due to Peter Brundrett of Microsoft for his proposal for an optimistic negotiation, and for Bill Sommerfeld of Epilogue Technology for his proposal for protecting the negotiation.
感谢SSE的Stephen Farrell、Stonecast的Marc Horowitz、RSA Laboratories的John Linn、Platinum Technology的Piers McMahon、ICL的Tom Parker和EINet的Doug Rosenthal审查本文件的早期版本并提供有用的信息。微软公司的彼得·布伦德雷特（Peter Brundrett）提出了一项乐观的谈判方案，而Epilogue Technology公司的比尔·索末菲（Bill Sommerfeld）则提出了保护谈判的方案。
APPENDIX A
附录A
GSS-API NEGOTIATION SUPPORT API
GSS-API协商支持API
In order to provide to a GSS-API caller (either the initiator or the target or both) the ability to choose among the set of supported mechanisms a reduced set of mechanisms for negotiation, two additional APIs are defined:
为了向GSS-API调用方（发起方或目标方或两者）提供从支持的机制集中选择一组简化的协商机制的能力，定义了两个额外的API：
GSS_Get_neg_mechs() indicates the set of security mechanisms available on the local system to the caller for negotiation.
GSS_Get_neg_mechs（）表示本地系统上可供调用者协商的一组安全机制。
GSS_Set_neg_mechs() specifies the set of security mechanisms to be used on the local system by the caller for negotiation.
GSS_Set_neg_mechs（）指定调用者在本地系统上用于协商的安全机制集。
Input: cred_handle CREDENTIAL HANDLE - NULL specifies default credentials mech_set SET OF OBJECT IDENTIFIER
输入：cred_handle CREDENTIAL handle-NULL指定对象标识符的默认凭据机制集
Outputs: major_status INTEGER, minor_status INTEGER,
输出：主\u状态整数，次\u状态整数，
Return major_status codes : GSS_S_COMPLETE indicates that the set of security mechanisms available for negotiation has been set to mech_set. GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
返回主要_状态代码：GSS_S_COMPLETE表示可用于协商的安全机制集已设置为mech_set。GSS_S_故障表示由于GSS-API级别未指定的原因，无法执行请求的操作。
Allows callers to specify the set of security mechanisms that may be negotiated with the credential identified by cred_handle. This call is intended for support of specialised 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 mechanism preference for the target.
允许调用者指定可与cred_handle标识的凭据协商的安全机制集。此调用旨在支持需要从调用方可用的所有安全机制集中限制可协商安全机制集（基于可用凭据）的专业调用方。请注意，如果在mech_集合中指定了多个机制，则指定这些机制的顺序意味着目标的相对机制首选项。
Input: cred_handle CREDENTIAL HANDLE - NULL specifies default credentials
输入：cred_handle CREDENTIAL handle-NULL指定默认凭据
Outputs: major_status INTEGER, minor_status INTEGER, mech_set SET OF OBJECT IDENTIFIER
输出：对象标识符的主要\ U状态整数、次要\ U状态整数、机械集合
Return major_status codes : GSS_S_COMPLETE indicates that the set of security mechanisms available for negotiation has been returned in mech_option_set. GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
返回主要\ U状态代码：GSS\ U S\ U COMPLETE表示可用于协商的安全机制集已在mech\ U选项\ U集中返回。GSS_S_故障表示由于GSS-API级别未指定的原因，无法执行请求的操作。
Allows callers to determine the set of security mechanisms available for negotiation with the credential identified by cred_handle. This call is intended for support of specialised 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（）函数表示本地系统上可用的全套机构类型。由于此调用没有输入参数，因此返回的集合不一定适用于所有凭据。
REFERENCES
参考资料
[1] Linn, J., "Generic Security Service Application Program Interface", RFC 2078, January 1997.
[1] 林恩，J.，“通用安全服务应用程序接口”，RFC 2078，1997年1月。
[2] Standard ECMA-206, "Association Context Management including Security Context Management", December 1993. Available on http://www.ecma.ch
[2] 标准ECMA-206，“关联上下文管理，包括安全上下文管理”，1993年12月。可于http://www.ecma.ch
AUTHORS' ADDRESSES
作者地址
Eric Baize Bull - 300 Concord Road Billerica, MA 01821 - USA
Eric Baize Bull-美国马萨诸塞州比尔里卡康科德路300号邮编01821
Phone: +1 978 294 61 37
Fax: +1 978 294 61 09
EMail: Eric.Baize@bull.com
Phone: +1 978 294 61 37
Fax: +1 978 294 61 09
EMail: Eric.Baize@bull.com
Denis Pinkas Bull Rue Jean-Jaures BP 68 78340 Les Clayes-sous-Bois - FRANCE
Denis Pinkas Bull Rue Jean Jaures BP 68 78340 Les Clays sous Bois-法国
Phone: +33 1 30 80 34 87
Fax: +33 1 30 80 33 21
EMail: Denis.Pinkas@bull.net
Phone: +33 1 30 80 34 87
Fax: +33 1 30 80 33 21
EMail: Denis.Pinkas@bull.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。