Network Working Group A. Melnikov, Ed.
Request for Comments: 4752 Isode
Obsoletes: 2222 November 2006
Category: Standards Track
Network Working Group A. Melnikov, Ed.
Request for Comments: 4752 Isode
Obsoletes: 2222 November 2006
Category: Standards Track
The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism
Kerberos V5（“GSSAPI”）简单身份验证和安全层（SASL）机制
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 IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
The Simple Authentication and Security Layer (SASL) is a framework for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface (GSS-API) Kerberos V5 in the SASL.
简单身份验证和安全层（SASL）是一个用于向基于连接的协议添加身份验证支持的框架。本文档描述了在SASL中使用通用安全服务应用程序接口（GSS-API）Kerberos V5的方法。
This document replaces Section 7.2 of RFC 2222, the definition of the "GSSAPI" SASL mechanism. This document, together with RFC 4422, obsoletes RFC 2222.
本文件取代RFC 2222第7.2节“GSSAPI”SASL机制的定义。本文件与RFC 4422一起废除了RFC 2222。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Relationship to Other Documents ............................2
2. Conventions Used in This Document ...............................2
3. Kerberos V5 GSS-API Mechanism ...................................2
3.1. Client Side of Authentication Protocol Exchange ............3
3.2. Server Side of Authentication Protocol Exchange ............4
3.3. Security Layer .............................................6
4. IANA Considerations .............................................7
5. Security Considerations .........................................7
6. Acknowledgements ................................................8
7. Changes since RFC 2222 ..........................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
1. Introduction ....................................................2
1.1. Relationship to Other Documents ............................2
2. Conventions Used in This Document ...............................2
3. Kerberos V5 GSS-API Mechanism ...................................2
3.1. Client Side of Authentication Protocol Exchange ............3
3.2. Server Side of Authentication Protocol Exchange ............4
3.3. Security Layer .............................................6
4. IANA Considerations .............................................7
5. Security Considerations .........................................7
6. Acknowledgements ................................................8
7. Changes since RFC 2222 ..........................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
This specification documents currently deployed Simple Authentication and Security Layer (SASL [SASL]) mechanism supporting the Kerberos V5 [KERBEROS] Generic Security Service Application Program Interface ([GSS-API]) mechanism [RFC4121]. The authentication sequence is described in Section 3. Note that the described authentication sequence has known limitations, in particular, it lacks channel bindings and the number of round-trips required to complete authentication exchange is not minimal. SASL WG is working on a separate document that should address these limitations.
本规范记录了当前部署的支持Kerberos V5[Kerberos]通用安全服务应用程序接口（[GSS-API]）机制[RFC4121]的简单身份验证和安全层（SASL[SASL]）机制。第3节描述了认证顺序。注意，所描述的身份验证序列具有已知的限制，特别是，它缺少通道绑定，并且完成身份验证交换所需的往返次数不是最小的。SASL工作组正在编写一份单独的文件，以解决这些限制。
This document, together with RFC 4422, obsoletes RFC 2222 in its entirety. This document replaces Section 7.2 of RFC 2222. The remainder is obsoleted as detailed in Section 1.2 of RFC 4422.
本文件连同RFC 4422完全废弃了RFC 2222。本文件取代RFC 2222第7.2节。剩余部分按照RFC 4422第1.2节的详细说明予以淘汰。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照“RFC中用于指示需求水平的关键词”中的定义进行解释[关键词]。
The SASL mechanism name for the Kerberos V5 GSS-API mechanism [RFC4121] is "GSSAPI". Though known as the SASL GSSAPI mechanism, the mechanism is specifically tied to Kerberos V5 and GSS-API's Kerberos V5 mechanism.
Kerberos V5 GSS-API机制[RFC4121]的SASL机制名称为“GSSAPI”。尽管被称为SASL GSSAPI机制，但该机制与Kerberos V5和GSS-API的Kerberos V5机制有着明确的联系。
The GSSAPI SASL mechanism is a "client goes first" SASL mechanism; i.e., it starts with the client sending a "response" created as described in the following section.
GSSAPI SASL机制是一种“客户先行”的SASL机制；i、 例如，它从客户端发送一个“响应”开始，该“响应”是按照以下部分中的描述创建的。
The implementation MAY set any GSS-API flags or arguments not mentioned in this specification as is necessary for the implementation to enforce its security policy.
实现可以设置本规范中未提及的任何GSS-API标志或参数，这是实现实施其安全策略所必需的。
Note that major status codes returned by GSS_Init_sec_context() or GSS_Accept_sec_context() other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED cause authentication failure. Major status codes returned by GSS_Unwrap() other than GSS_S_COMPLETE (without any additional supplementary status codes) cause authentication and/or security layer failure.
请注意，由GSS_Init_sec_context（）或GSS_Accept_sec_context（）返回的除GSS_S_COMPLETE或GSS_CONTINUE_所需之外的主要状态代码会导致身份验证失败。GSS_Unwrap（）返回的除GSS_S_COMPLETE之外的主要状态代码（没有任何附加的补充状态代码）会导致身份验证和/或安全层失败。
The client calls GSS_Init_sec_context, passing in input_context_handle of 0 (initially), mech_type of the Kerberos V5 GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name equal to output_name from GSS_Import_Name called with input_name_type of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of "service@hostname" where "service" is the service name specified in the protocol's profile, and "hostname" is the fully qualified host name of the server. When calling the GSS_Init_sec_context, the client MUST pass the integ_req_flag of TRUE (**). If the client will be requesting a security layer, it MUST also supply to the GSS_Init_sec_context a mutual_req_flag of TRUE, and a sequence_req_flag of TRUE. If the client will be requesting a security layer providing confidentiality protection, it MUST also supply to the GSS_Init_sec_context a conf_req_flag of TRUE. The client then responds with the resulting output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client should expect the server to issue a token in a subsequent challenge. The client must pass the token to another call to GSS_Init_sec_context, repeating the actions in this paragraph.
客户机调用GSS_Init_sec_context，传入0的输入_context_句柄（最初）、Kerberos V5 GSS-API机制[KRB5GSS]的mech_类型、NULL的chan_绑定和等于GSS_Import_name的输出_name的target_name，并使用输入_name_类型的GSS_C_NT_HOSTBASED_服务（*）和输入_name_字符串“service@hostname“服务”在哪里是协议配置文件中指定的服务名称，“主机名”是服务器的完全限定主机名。调用GSS_Init_sec_上下文时，客户机必须传递TRUE（**）的integ_req_标志。如果客户端将请求一个安全层，它还必须向GSS_Init_sec_上下文提供一个mutual_req_标志TRUE和一个sequence_req_标志TRUE。如果客户机将请求提供保密保护的安全层，它还必须向GSS_Init_sec_上下文提供一个conf_req_标志TRUE。然后，客户机使用生成的输出令牌进行响应。如果GSS_Init_sec_上下文返回GSS_S_CONTINUE_NEEDED，那么客户端应该期望服务器在后续质询中发出令牌。客户端必须将令牌传递给另一个对GSS_Init_sec_上下文的调用，重复本段中的操作。
(*) Clients MAY use name types other than GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names, but only when they have a priori knowledge that the servers support alternate name types. Otherwise clients MUST use GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names.
（*）客户端可以使用GSS_C_NT_HOSTBASED_服务以外的名称类型来导入服务器的接受者名称，但前提是它们事先知道服务器支持备用名称类型。否则，客户端必须使用GSS_C_NT_HOSTBASED_服务来导入接受程序名称。
(**) Note that RFC 2222 [RFC2222] implementations will not work with GSS-API implementations that require integ_req_flag to be true. No implementations of RFC 1964 [KRB5GSS] or RFC 4121 [RFC4121] that require integ_req_flag to be true are believed to exist and it is expected that any future update to [RFC4121] will require that
（**）请注意，RFC 2222[RFC2222]实现将不适用于要求integ_req_标志为true的GSS-API实现。据信不存在要求integ_req_标志为真的RFC 1964[KRB5GSS]或RFC 4121[RFC4121]的实现，并且预计将来对[RFC4121]的任何更新都需要该标志
integrity be available even in not explicitly requested by the application.
完整性即使在应用程序未明确请求的情况下也可以使用。
When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines the context to ensure that it provides a level of protection permitted by the client's security policy. In particular, if the integ_avail flag is not set in the context, then no security layer can be offered or accepted.
当GSS_Init_sec_context返回GSS_S_COMPLETE时，客户端将检查该上下文以确保它提供客户端安全策略允许的保护级别。特别是，如果未在上下文中设置integ_avail标志，则无法提供或接受任何安全层。
If the conf_avail flag is not set in the context, then no security layer with confidentiality can be offered or accepted. If the context is acceptable, the client takes the following actions: If the last call to GSS_Init_sec_context returned an output_token, then the client responds with the output_token, otherwise the client responds with no data. The client should then expect the server to issue a token in a subsequent challenge. The client passes this token to GSS_Unwrap and interprets the first octet of resulting cleartext as a bit-mask specifying the security layers supported by the server and the second through fourth octets as the maximum size output_message the server is able to receive (in network byte order). If the resulting cleartext is not 4 octets long, the client fails the negotiation. The client verifies that the server maximum buffer is 0 if the server does not advertise support for any security layer.
如果上下文中未设置conf_avail标志，则不能提供或接受具有机密性的安全层。如果上下文是可接受的，则客户端将采取以下操作：如果对GSS_Init_sec_上下文的最后一次调用返回了输出_令牌，则客户端将使用输出_令牌进行响应，否则客户端将不响应任何数据。然后，客户机应该期望服务器在后续质询中发出令牌。客户端将此令牌传递给GSS_Unwrap，并将生成的明文的第一个八位字节解释为位掩码，指定服务器支持的安全层，第二个到第四个八位字节解释为服务器能够接收的最大大小输出_消息（以网络字节顺序）。如果生成的明文长度不是4个八位字节，则客户端协商失败。如果服务器未公布对任何安全层的支持，客户端将验证服务器最大缓冲区是否为0。
The client then constructs data, with the first octet containing the bit-mask specifying the selected security layer, the second through fourth octets containing in network byte order the maximum size output_message the client is able to receive (which MUST be 0 if the client does not support any security layer), and the remaining octets containing the UTF-8 [UTF8] encoded authorization identity. (Implementation note: The authorization identity is not terminated with the zero-valued (%x00) octet (e.g., the UTF-8 encoding of the NUL (U+0000) character)). The client passes the data to GSS_Wrap with conf_flag set to FALSE and responds with the generated output_message. The client can then consider the server authenticated.
然后，客户端构造数据，第一个八位字节包含指定所选安全层的位掩码，第二到第四个八位字节包含客户端能够接收的最大大小输出消息（如果客户端不支持任何安全层，则必须为0），以及包含UTF-8[UTF8]编码的授权标识的剩余八位字节。（实施说明：授权标识不以零值（%x00）八位字节终止（例如，NUL（U+0000）字符的UTF-8编码）。客户端将数据传递给GSS_Wrap，conf_标志设置为FALSE，并使用生成的输出_消息进行响应。然后客户端可以考虑服务器验证了。
A server MUST NOT advertise support for the "GSSAPI" SASL mechanism described in this document unless it has acceptor credential for the Kerberos V GSS-API mechanism [KRB5GSS].
除非具有Kerberos V GSS-API机制[KRB5GSS]的接受者凭据，否则服务器不得公布对本文档中描述的“GSSAPI”SASL机制的支持。
The server passes the initial client response to GSS_Accept_sec_context as input_token, setting input_context_handle to 0 (initially), chan_binding of NULL, and a suitable acceptor_cred_handle (see below). If GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
服务器将初始客户端响应传递给GSS_Accept_sec_context作为输入_令牌，将输入_context_句柄设置为0（初始），将chan_绑定设置为NULL，并使用合适的接受器_cred_句柄（见下文）。如果GSS_Accept_sec_上下文返回所需的GSS_CONTINUE_，服务器将返回生成的输出_令牌
to the client in challenge and passes the resulting response to another call to GSS_Accept_sec_context, repeating the actions in this paragraph.
将结果响应传递给另一个对GSS_Accept_sec_context的调用，重复本段中的操作。
Servers SHOULD use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the Object Identifier (OID) of the Kerberos V5 GSS-API mechanism [KRB5GSS](*). Servers MAY use GSS_C_NO_CREDENTIAL as an acceptor credential handle. Servers MAY use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred for the server's principal name(s) (**) and the Kerberos V5 GSS-API mechanism [KRB5GSS].
服务器应使用通过调用GSS_Acquire_cred或GSS_Add_cred获得的凭据，以获取所需的GSS_C_NO_NAME_NAME_NAME和Kerberos V5 GSS-API机制[KRB5GSS]（*）的对象标识符（OID）。服务器可以使用GSS_C_NO_凭证作为接受者凭证句柄。服务器可以使用通过调用GSS_Acquire_cred或GSS_Add_cred获得的凭据作为服务器的主体名称（**）和Kerberos V5 GSS-API机制[KRB5GSS]。
(*) Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of GSS-API mechanism as an input parameter. The OID set can be created by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member. It can be freed by calling the GSS_Release_oid_set.
（*）与GSS_Add_cred不同，GSS_Acquire_cred使用一组GSS-API机制作为输入参数。可以使用GSS_创建_空_OID_集和GSS_添加_OID_集成员创建OID集。可以通过调用GSS_Release_oid_集合来释放它。
(**) Use of server's principal names having GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format, where "service" is the service name specified in the protocol's profile, and "hostname" is the fully qualified host name of the server, is RECOMMENDED. The server name is generated by calling GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE and input_name_string of "service@hostname".
（**）使用具有GSS_C_NT_HOSTBASED_服务名称类型和“”的服务器主体名称service@hostname建议使用“服务”格式，其中“服务”是协议配置文件中指定的服务名称，“主机名”是服务器的完全限定主机名。通过调用GSS\U导入\U名称生成服务器名称，输入\U名称\U类型为GSS\U C\U NT\U基于主机的\U服务，输入\U名称\U字符串为“service@hostname".
Upon successful establishment of the security context (i.e., GSS_Accept_sec_context returns GSS_S_COMPLETE), the server SHOULD verify that the negotiated GSS-API mechanism is indeed Kerberos V5 [KRB5GSS]. This is done by examining the value of the mech_type parameter returned from the GSS_Accept_sec_context call. If the value differs, SASL authentication MUST be aborted.
成功建立安全上下文（即GSS_Accept_sec_context返回GSS_S_COMPLETE）后，服务器应验证协商的GSS-API机制确实是Kerberos V5[KRB5GSS]。这是通过检查从GSS_Accept_sec_上下文调用返回的mech_type参数的值来完成的。如果值不同，则必须中止SASL身份验证。
Upon successful establishment of the security context and if the server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor credential handle, the server SHOULD also check using the GSS_Inquire_context that the target_name used by the client matches either
成功建立安全上下文后，如果服务器使用GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL创建接受方凭据句柄，则服务器还应使用GSS_Inquire_上下文检查客户端使用的目标名称是否匹配
- the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax, where "service" is the service name specified in the application protocol's profile,
- GSS_C_NT_基于主机的_服务”service@hostname名称语法，其中“service”是应用程序协议概要文件中指定的服务名称，
or
或
- the GSS_KRB5_NT_PRINCIPAL_NAME [KRB5GSS] name syntax for a two-component principal where the first component matches the service name specified in the application protocol's profile.
- 双组件主体的GSS_KRB5_NT_PRINCIPAL_NAME[KRB5GSS]名称语法，其中第一个组件与应用程序协议概要文件中指定的服务名称匹配。
When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server examines the context to ensure that it provides a level of protection permitted by the server's security policy. In particular, if the integ_avail flag is not set in the context, then no security layer can be offered or accepted. If the conf_avail flag is not set in the context, then no security layer with confidentiality can be offered or accepted.
当GSS_Accept_sec_context返回GSS_S_COMPLETE时，服务器将检查该上下文以确保它提供了服务器安全策略允许的保护级别。特别是，如果未在上下文中设置integ_avail标志，则无法提供或接受任何安全层。如果上下文中未设置conf_avail标志，则不能提供或接受具有机密性的安全层。
If the context is acceptable, the server takes the following actions: If the last call to GSS_Accept_sec_context returned an output_token, the server returns it to the client in a challenge and expects a reply from the client with no data. Whether or not an output_token was returned (and after receipt of any response from the client to such an output_token), the server then constructs 4 octets of data, with the first octet containing a bit-mask specifying the security layers supported by the server and the second through fourth octets containing in network byte order the maximum size output_token the server is able to receive (which MUST be 0 if the server does not support any security layer). The server must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE and issue the generated output_message to the client in a challenge.
如果上下文可接受，服务器将采取以下操作：如果对GSS_Accept_sec_context的最后一次调用返回了一个输出_令牌，服务器将在质询中将其返回给客户端，并期望客户端在没有数据的情况下作出答复。无论是否返回了输出_令牌（以及在收到客户端对该输出_令牌的任何响应后），服务器都会构造4个八位字节的数据，第一个八位字节包含指定服务器支持的安全层的位掩码，第二到第四个八位字节包含服务器能够接收的最大大小输出令牌（如果服务器不支持任何安全层，则必须为0）。然后，服务器必须将明文传递给GSS_Wrap，conf_标志设置为FALSE，并在质询中向客户端发出生成的输出_消息。
The server must then pass the resulting response to GSS_Unwrap and interpret the first octet of resulting cleartext as the bit-mask for the selected security layer, the second through fourth octets as the maximum size output_message the client is able to receive (in network byte order), and the remaining octets as the authorization identity. The server verifies that the client has selected a security layer that was offered and that the client maximum buffer is 0 if no security layer was chosen. The server must verify that the src_name is authorized to act as the authorization identity. After these verifications, the authentication process is complete. The server is not expected to return any additional data with the success indicator.
然后，服务器必须将结果响应传递给GSS_Unwrap，并将结果明文的第一个八位字节解释为所选安全层的位掩码，第二到第四个八位字节解释为客户端能够接收的最大大小输出_消息（按网络字节顺序），其余八位字节解释为授权标识。服务器验证客户端是否选择了提供的安全层，如果未选择安全层，则验证客户端最大缓冲区是否为0。服务器必须验证src_名称是否被授权作为授权标识。在这些验证之后，身份验证过程就完成了。服务器不应返回带有成功指示器的任何其他数据。
The security layers and their corresponding bit-masks are as follows:
安全层及其对应的位掩码如下所示：
1 No security layer 2 Integrity protection. Sender calls GSS_Wrap with conf_flag set to FALSE 4 Confidentiality protection. Sender calls GSS_Wrap with conf_flag set to TRUE
1无安全层2完整性保护。发送方调用GSS_Wrap，conf_标志设置为FALSE 4保密保护。发送方调用GSS_Wrap，conf_标志设置为TRUE
Other bit-masks may be defined in the future; bits that are not understood must be negotiated off.
将来可以定义其他位掩码；未理解的位必须协商关闭。
When decoding any received data with GSS_Unwrap, the major_status other than the GSS_S_COMPLETE MUST be treated as a fatal error.
使用GSS_展开对任何接收到的数据进行解码时，除GSS_S_完成之外的主要_状态必须视为致命错误。
Note that SASL negotiates the maximum size of the output_message to send. Implementations can use the GSS_Wrap_size_limit call to determine the corresponding maximum size input_message.
请注意，SASL协商要发送的输出消息的最大大小。实现可以使用GSS\u Wrap\u size\u limit调用来确定相应的最大大小输入消息。
IANA modified the existing registration for "GSSAPI" as follows:
IANA将“GSSAPI”的现有注册修改如下：
Family of SASL mechanisms: NO
SASL机构系列：否
SASL mechanism name: GSSAPI
SASL机构名称：GSSAPI
Security considerations: See Section 5 of RFC 4752
安全注意事项：见RFC 4752第5节
Published specification: RFC 4752
已发布规范：RFC 4752
Person & email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Person & email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Intended usage: COMMON
预期用途：普通
Owner/Change controller: iesg@ietf.org
Owner/Change controller: iesg@ietf.org
Additional information: This mechanism is for the Kerberos V5 mechanism of GSS-API.
附加信息：此机制适用于GSS-API的Kerberos V5机制。
Security issues are discussed throughout this memo.
本备忘录中讨论了安全问题。
When constructing the input_name_string, the client SHOULD NOT canonicalize the server's fully qualified domain name using an insecure or untrusted directory service.
构造输入\u name\u字符串时，客户端不应使用不安全或不受信任的目录服务规范化服务器的完全限定域名。
For compatibility with deployed software, this document requires that the chan_binding (channel bindings) parameter to GSS_Init_sec_context and GSS_Accept_sec_context be NULL, hence disallowing use of GSS-API support for channel bindings. GSS-API channel bindings in SASL is expected to be supported via a new GSS-API family of SASL mechanisms (to be introduced in a future document).
为了与已部署的软件兼容，本文档要求GSS_Init_sec_上下文和GSS_Accept_sec_上下文的chan_binding（通道绑定）参数为空，因此不允许使用GSS-API支持通道绑定。SASL中的GSS-API通道绑定预计将通过新的GSS-API系列SASL机制（将在未来的文档中介绍）得到支持。
Additional security considerations are in the [SASL] and [GSS-API] specifications. Additional security considerations for the GSS-API mechanism can be found in [KRB5GSS] and [KERBEROS].
[SASL]和[GSS-API]规范中有其他安全注意事项。GSS-API机制的其他安全注意事项可以在[KRB5GSS]和[KERBEROS]中找到。
This document replaces Section 7.2 of RFC 2222 [RFC2222] by John G. Myers. He also contributed significantly to this revision.
本文件由John G.Myers取代RFC 2222[RFC2222]第7.2节。他也为这次修订作出了重大贡献。
Lawrence Greenfield converted text of this document to the XML format.
Lawrence Greenfield将此文档的文本转换为XML格式。
Contributions of many members of the SASL mailing list are gratefully acknowledged, in particular comments from Chris Newman, Nicolas Williams, Jeffrey Hutzelman, Sam Hartman, Mark Crispin, and Martin Rex.
感谢SASL邮件列表中许多成员的贡献，特别是Chris Newman、Nicolas Williams、Jeffrey Hutzelman、Sam Hartman、Mark Crispin和Martin Rex的评论。
RFC 2078 [RFC2078] specifies the version of GSS-API used by RFC 2222 [RFC2222], which provided the original version of this specification. That version of GSS-API did not provide the integ_integ_avail flag as an input to GSS_Init_sec_context. Instead, integrity was always requested. RFC 4422 [SASL] requires that when possible, the security layer negotiation be integrity protected. To meet this requirement and as part of moving from RFC 2078 [RFC2078] to RFC 2743 [GSS-API], this specification requires that clients request integrity from GSS_Init_sec_context so they can use GSS_Wrap to protect the security layer negotiation. This specification does not require that the mechanism offer the integrity security layer, simply that the security layer negotiation be wrapped.
RFC 2078[RFC2078]规定了RFC 2222[RFC2222]使用的GSS-API版本，该版本提供了本规范的原始版本。该版本的GSS-API没有提供integ_integ_avail标志作为GSS_Init_sec_上下文的输入。相反，人们总是要求诚信。RFC 4422[SASL]要求在可能的情况下，对安全层协商进行完整性保护。为了满足这一要求，并作为从RFC 2078[RFC2078]转移到RFC 2743[GSS-API]的一部分，本规范要求客户机从GSS_Init_sec_上下文请求完整性，以便他们可以使用GSS_Wrap来保护安全层协商。本规范不要求该机制提供完整性安全层，只要求对安全层进行封装。
[GSS-API] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[GSS-API]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[KERBEROS] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[KERBEROS]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“KERBEROS网络身份验证服务（V5）”，RFC41202005年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[KRB5GSS] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[KRB5GSS]Linn，J.，“Kerberos版本5 GSS-API机制”，RFC1964，1996年6月。
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
[RFC4121]Zhu，L.，Jaganathan，K.，和S.Hartman，“Kerberos版本5通用安全服务应用程序接口（GSS-API）机制：版本2”，RFC 41212005年7月。
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL]Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[RFC2078]Linn，J.，“通用安全服务应用程序接口，第2版”，RFC 2078，1997年1月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC2222]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
Editor's Address
编辑地址
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Alexey Melnikov Isode Limited TW12 2BX
EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/
EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。