Network Working Group J. Myers
Request for Comments: 2222 Netscape Communications
Category: Standards Track October 1997
Network Working Group J. Myers
Request for Comments: 2222 Netscape Communications
Category: Standards Track October 1997
Simple Authentication and Security Layer (SASL)
简单身份验证和安全层（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 Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
Table of Contents
目录
1. Abstract .............................................. 2
2. Organization of this Document ......................... 2
2.1. How to Read This Document ............................. 2
2.2. Conventions Used in this Document ..................... 2
2.3. Examples .............................................. 3
3. Introduction and Overview ............................. 3
4. Profiling requirements ................................ 4
5. Specific issues ....................................... 5
5.1. Client sends data first ............................... 5
5.2. Server returns success with additional data ........... 5
5.3. Multiple authentications .............................. 5
6. Registration procedures ............................... 6
6.1. Comments on SASL mechanism registrations .............. 6
6.2. Location of Registered SASL Mechanism List ............ 6
6.3. Change Control ........................................ 7
6.4. Registration Template ................................. 7
7. Mechanism definitions ................................. 8
7.1. Kerberos version 4 mechanism .......................... 8
7.2. GSSAPI mechanism ...................................... 9
7.2.1 Client side of authentication protocol exchange ....... 9
7.2.2 Server side of authentication protocol exchange ....... 10
7.2.3 Security layer ........................................ 11
7.3. S/Key mechanism ....................................... 11
7.4. External mechanism .................................... 12
8. References ............................................ 13
9. Security Considerations ............................... 13
10. Author's Address ...................................... 14
1. Abstract .............................................. 2
2. Organization of this Document ......................... 2
2.1. How to Read This Document ............................. 2
2.2. Conventions Used in this Document ..................... 2
2.3. Examples .............................................. 3
3. Introduction and Overview ............................. 3
4. Profiling requirements ................................ 4
5. Specific issues ....................................... 5
5.1. Client sends data first ............................... 5
5.2. Server returns success with additional data ........... 5
5.3. Multiple authentications .............................. 5
6. Registration procedures ............................... 6
6.1. Comments on SASL mechanism registrations .............. 6
6.2. Location of Registered SASL Mechanism List ............ 6
6.3. Change Control ........................................ 7
6.4. Registration Template ................................. 7
7. Mechanism definitions ................................. 8
7.1. Kerberos version 4 mechanism .......................... 8
7.2. GSSAPI mechanism ...................................... 9
7.2.1 Client side of authentication protocol exchange ....... 9
7.2.2 Server side of authentication protocol exchange ....... 10
7.2.3 Security layer ........................................ 11
7.3. S/Key mechanism ....................................... 11
7.4. External mechanism .................................... 12
8. References ............................................ 13
9. Security Considerations ............................... 13
10. Author's Address ...................................... 14
Appendix A. Relation of SASL to Transport Security .......... 15
Full Copyright Statement .................................... 16
Appendix A. Relation of SASL to Transport Security .......... 15
Full Copyright Statement .................................... 16
This document describes a method for adding authentication support to connection-based protocols. To use this specification, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection. This document describes how a protocol specifies such a command, defines several mechanisms for use by the command, and defines the protocol used for carrying a negotiated security layer over the connection.
本文档描述了一种向基于连接的协议添加身份验证支持的方法。为了使用该规范，协议包括用于向服务器标识和认证用户以及可选地协商后续协议交互的保护的命令。如果协商使用，则在协议和连接之间插入一个安全层。本文档描述协议如何指定此类命令，定义命令使用的几种机制，以及定义用于在连接上承载协商安全层的协议。
This document is written to serve two different audiences, protocol designers using this specification to support authentication in their protocol, and implementors of clients or servers for those protocols using this specification.
本文档旨在为两个不同的受众服务，一个是使用本规范支持其协议中的身份验证的协议设计人员，另一个是使用本规范支持这些协议的客户端或服务器的实现人员。
The sections "Introduction and Overview", "Profiling requirements", and "Security Considerations" cover issues that protocol designers need to understand and address in profiling this specification for use in a specific protocol.
“简介和概述”、“评测要求”和“安全注意事项”部分涵盖了协议设计者在评测本规范以用于特定协议时需要理解和解决的问题。
Implementors of a protocol using this specification need the protocol-specific profiling information in addition to the information in this document.
除了本文档中的信息外，使用本规范的协议的实现者还需要特定于协议的概要信息。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
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" [RFC 2119].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照“RFC中用于表示需求水平的关键词”中的定义进行解释[RFC 2119]。
Examples in this document are for the IMAP profile [RFC 2060] of this specification. The base64 encoding of challenges and responses, as well as the "+ " preceding the responses are part of the IMAP4 profile, not part of the SASL specification itself.
本文件中的示例适用于本规范的IMAP配置文件[RFC 2060]。质询和响应的base64编码以及响应前的“+”是IMAP4配置文件的一部分，而不是SASL规范本身的一部分。
The Simple Authentication and Security Layer (SASL) is a method for adding authentication support to connection-based protocols. To use this specification, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating a security layer for subsequent protocol interactions.
简单身份验证和安全层（SASL）是一种向基于连接的协议添加身份验证支持的方法。为了使用该规范，协议包括用于向服务器标识和认证用户的命令，以及用于可选地协商用于后续协议交互的安全层的命令。
The command has a required argument identifying a SASL mechanism. SASL mechanisms are named by strings, from 1 to 20 characters in length, consisting of upper-case letters, digits, hyphens, and/or underscores. SASL mechanism names must be registered with the IANA. Procedures for registering new SASL mechanisms are given in the section "Registration procedures"
该命令具有标识SASL机制的必需参数。SASL机制由字符串命名，长度从1到20个字符，由大写字母、数字、连字符和/或下划线组成。SASL机制名称必须向IANA注册。新SASL机制的注册程序见“注册程序”一节
If a server supports the requested mechanism, it initiates an authentication protocol exchange. This consists of a series of server challenges and client responses that are specific to the requested mechanism. The challenges and responses are defined by the mechanisms as binary tokens of arbitrary length. The protocol's profile then specifies how these binary tokens are then encoded for transfer over the connection.
如果服务器支持请求的机制，它将启动身份验证协议交换。这包括一系列特定于请求机制的服务器挑战和客户端响应。这些机制将挑战和响应定义为任意长度的二进制令牌。然后，协议的概要文件指定如何对这些二进制令牌进行编码，以便通过连接进行传输。
After receiving the authentication command or any client response, a server may issue a challenge, indicate failure, or indicate completion. The protocol's profile specifies how the server indicates which of the above it is doing.
在接收到身份验证命令或任何客户端响应后，服务器可能发出质询、指示失败或指示完成。协议的配置文件指定服务器如何指示它正在执行上述操作。
After receiving a challenge, a client may issue a response or abort the exchange. The protocol's profile specifies how the client indicates which of the above it is doing.
收到质询后，客户端可能会发出响应或中止交换。协议的配置文件指定客户端如何指示它正在执行上述哪项操作。
During the authentication protocol exchange, the mechanism performs authentication, transmits an authorization identity (frequently known as a userid) from the client to server, and negotiates the use of a mechanism-specific security layer. If the use of a security layer is agreed upon, then the mechanism must also define or negotiate the maximum cipher-text buffer size that each side is able to receive.
在身份验证协议交换期间，该机制执行身份验证，将授权标识（通常称为用户标识）从客户端传输到服务器，并协商特定于机制的安全层的使用。如果同意使用安全层，则该机制还必须定义或协商各方能够接收的最大密文缓冲区大小。
The transmitted authorization identity may be different than the identity in the client's authentication credentials. This permits agents such as proxy servers to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying. With any mechanism, transmitting an authorization identity of the empty string directs the server to derive an authorization identity from the client's authentication credentials.
传输的授权标识可能不同于客户端身份验证凭据中的标识。这允许代理服务器（如代理服务器）使用其自己的凭据进行身份验证，同时请求其代理的身份的访问权限。通过任何机制，传输空字符串的授权标识都会指示服务器从客户端的身份验证凭据派生授权标识。
If use of a security layer is negotiated, it is applied to all subsequent data sent over the connection. The security layer takes effect immediately following the last response of the authentication exchange for data sent by the client and the completion indication for data sent by the server. Once the security layer is in effect, the protocol stream is processed by the security layer into buffers of cipher-text. Each buffer is transferred over the connection as a stream of octets prepended with a four octet field in network byte order that represents the length of the following buffer. The length of the cipher-text buffer must be no larger than the maximum size that was defined or negotiated by the other side.
如果协商使用安全层，它将应用于通过连接发送的所有后续数据。安全层在客户端发送的数据的身份验证交换的最后一次响应和服务器发送的数据的完成指示之后立即生效。一旦安全层生效，安全层就会将协议流处理到密文缓冲区中。每个缓冲区作为八位字节流在连接上传输，八位字节流前面有一个网络字节顺序的四位八位字节字段，表示以下缓冲区的长度。密文缓冲区的长度不得大于另一方定义或协商的最大大小。
In order to use this specification, a protocol definition must supply the following information:
为了使用本规范，协议定义必须提供以下信息：
1. A service name, to be selected from the IANA registry of "service" elements for the GSSAPI host-based service name form [RFC 2078].
1. 服务名称，从GSSAPI基于主机的服务名称表[RFC 2078]的“服务”元素IANA注册表中选择。
2. A definition of the command to initiate the authentication protocol exchange. This command must have as a parameter the mechanism name being selected by the client.
2. 用于启动身份验证协议交换的命令的定义。此命令必须将客户端选择的机构名称作为参数。
The command SHOULD have an optional parameter giving an initial response. This optional parameter allows the client to avoid a round trip when using a mechanism which is defined to have the client send data first. When this initial response is sent by the client and the selected mechanism is defined to have the server start with an initial challenge, the command fails. See section 5.1 of this document for further information.
该命令应该有一个可选参数，提供初始响应。此可选参数允许客户端在使用定义为让客户端先发送数据的机制时避免往返。当此初始响应由客户端发送，并且所选机制被定义为让服务器以初始质询启动时，该命令将失败。详见本文件第5.1节。
3. A definition of the method by which the authentication protocol exchange is carried out, including how the challenges and responses are encoded, how the server indicates completion or failure of the exchange, how the client aborts an exchange, and how the exchange method interacts with any line length limits in the protocol.
3. 执行身份验证协议交换的方法的定义，包括如何对质询和响应进行编码，服务器如何指示交换的完成或失败，客户端如何中止交换，以及交换方法如何与协议中的任何行长度限制交互。
4. Identification of the octet where any negotiated security layer starts to take effect, in both directions.
4. 在任何协商的安全层开始在两个方向上生效的八位组的标识。
5. A specification of how the authorization identity passed from the client to the server is to be interpreted.
5. 如何解释从客户端传递到服务器的授权标识的规范。
Some mechanisms specify that the first data sent in the authentication protocol exchange is from the client to the server.
某些机制指定在身份验证协议交换中发送的第一个数据是从客户端发送到服务器的。
If a protocol's profile permits the command which initiates an authentication protocol exchange to contain an initial client response, this parameter SHOULD be used with such mechanisms.
如果协议的配置文件允许启动身份验证协议交换的命令包含初始客户端响应，则此参数应与此类机制一起使用。
If the initial client response parameter is not given, or if a protocol's profile does not permit the command which initiates an authentication protocol exchange to contain an initial client response, then the server issues a challenge with no data. The client's response to this challenge is then used as the initial client response. (The server then proceeds to send the next challenge, indicates completion, or indicates failure.)
如果未给出初始客户机响应参数，或者协议的配置文件不允许启动身份验证协议交换的命令包含初始客户机响应，则服务器将发出无数据的质询。然后，客户端对此质询的响应将用作初始客户端响应。（然后服务器继续发送下一个质询，指示完成或指示失败。）
Some mechanisms may specify that server challenge data be sent to the client along with an indication of successful completion of the exchange. This data would, for example, authenticate the server to the client.
一些机制可以指定将服务器质询数据发送到客户端，同时指示交换成功完成。例如，该数据将向客户机验证服务器。
If a protocol's profile does not permit this server challenge to be returned with a success indication, then the server issues the server challenge without an indication of successful completion. The client then responds with no data. After receiving this empty response, the server then indicates successful completion.
如果协议的配置文件不允许此服务器质询返回成功指示，则服务器发出服务器质询而不指示成功完成。然后，客户机响应时没有数据。收到此空响应后，服务器将指示成功完成。
Unless otherwise stated by the protocol's profile, only one successful SASL negotiation may occur in a protocol session. In this case, once an authentication protocol exchange has successfully completed, further attempts to initiate an authentication protocol exchange fail.
除非协议配置文件另有规定，否则在协议会话中只能发生一次成功的SASL协商。在这种情况下，一旦验证协议交换成功完成，启动验证协议交换的进一步尝试将失败。
In the case that a profile explicitly permits multiple successful SASL negotiations to occur, then in no case may multiple security layers be simultaneously in effect. If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer remains in effect. If a security layer is in effect and a subsequent SASL negotiation selects a second security layer, then the second security layer replaces the first.
如果概要文件明确允许多个成功的SASL协商发生，那么在任何情况下，多个安全层都不能同时生效。如果某个安全层有效，并且后续SASL协商未选择任何安全层，则原始安全层仍有效。如果安全层生效，并且后续SASL协商选择第二个安全层，则第二个安全层将替换第一个安全层。
Registration of a SASL mechanism is done by filling in the template in section 6.4 and sending it in to iana@isi.edu. IANA has the right to reject obviously bogus registrations, but will perform no review of clams made in the registration form.
SASL机制的注册是通过填写第6.4节中的模板并将其发送到iana@isi.edu. IANA有权拒绝明显虚假的注册，但不会对注册表中的蛤蜊进行审查。
There is no naming convention for SASL mechanisms; any name that conforms to the syntax of a SASL mechanism name can be registered.
SASL机制没有命名约定；任何符合SASL机制名称语法的名称都可以注册。
While the registration procedures do not require it, authors of SASL mechanisms are encouraged to seek community review and comment whenever that is feasible. Authors may seek community review by posting a specification of their proposed mechanism as an internet-draft. SASL mechanisms intended for widespread use should be standardized through the normal IETF process, when appropriate.
虽然注册程序不要求，但鼓励SASL机制的作者在可行的情况下寻求社区审查和评论。作者可以通过将其建议机制的规范发布为互联网草案来寻求社区审查。在适当的情况下，应通过正常的IETF过程对广泛使用的SASL机制进行标准化。
Comments on registered SASL mechanisms should first be sent to the "owner" of the mechanism. Submitters of comments may, after a reasonable attempt to contact the owner, request IANA to attach their comment to the SASL mechanism registration itself. If IANA approves of this the comment will be made accessible in conjunction with the SASL mechanism registration itself.
关于已注册SASL机制的评论应首先发送给该机制的“所有者”。在合理尝试联系所有者后，意见提交人可要求IANA将其意见附在SASL机制注册本身上。如果IANA批准，评论将与SASL机制注册本身一起提供。
SASL mechanism registrations will be posted in the anonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-mechanisms/" and all registered SASL mechanisms will be listed in the periodically issued "Assigned Numbers" RFC [currently STD 2, RFC 1700]. The SASL mechanism description and other supporting material may also be published as an Informational RFC by sending it to "rfc-editor@isi.edu" (please follow the instructions to RFC authors [RFC 2223]).
SASL机制注册将发布在匿名FTP目录中“ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-mechanisms/所有注册的SASL机制将被列入定期发布的“分配编号”RFC[目前为STD 2，RFC 1700]。SASL机制说明和其他支持材料也可以通过发送给“RFC”作为信息RFC发布-editor@isi.edu“（请遵循RFC作者须知[RFC 2223]）。
Once a SASL mechanism registration has been published by IANA, the author may request a change to its definition. The change request follows the same procedure as the registration request.
IANA发布SASL机制注册后，作者可要求更改其定义。变更请求遵循与注册请求相同的程序。
The owner of a SASL mechanism may pass responsibility for the SASL mechanism to another person or agency by informing IANA; this can be done without discussion or review.
SASL机制的所有者可以通过通知IANA将SASL机制的责任转移给另一个人或机构；这可以在不进行讨论或审查的情况下完成。
The IESG may reassign responsibility for a SASL mechanism. The most common case of this will be to enable changes to be made to mechanisms where the author of the registration has died, moved out of contact or is otherwise unable to make changes that are important to the community.
IESG可以重新分配SASL机制的责任。最常见的情况是，当注册作者去世、失去联系或无法进行对社区重要的更改时，可以对机制进行更改。
SASL mechanism registrations may not be deleted; mechanisms which are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field; such SASL mechanisms will be clearly marked in the lists published by IANA.
不得删除SASL机制注册；通过更改“预期用途”字段，可以宣布不再适合使用的机制已过时；IANA发布的清单中将明确标明此类SASL机制。
The IESG is considered to be the owner of all SASL mechanisms which are on the IETF standards track.
IESG被认为是IETF标准轨道上所有SASL机制的所有者。
To: iana@iana.org Subject: Registration of SASL mechanism X
致：iana@iana.org主题：SASL机制X的注册
SASL mechanism name:
SASL机制名称：
Security considerations:
安全考虑：
Published specification (optional, recommended):
发布的规范（可选，推荐）：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Intended usage:
预期用途：
(One of COMMON, LIMITED USE or OBSOLETE)
（常用、有限使用或过时的）
Author/Change controller:
作者/变更控制员：
(Any other information that the author deems interesting may be added below this line.)
（作者认为有趣的任何其他信息可添加在此行下方。）
The following mechanisms are hereby defined.
特此定义以下机制。
The mechanism name associated with Kerberos version 4 is "KERBEROS_V4".
与Kerberos版本4关联的机制名称为“Kerberos_V4”。
The first challenge consists of a random 32-bit number in network byte order. The client responds with a Kerberos ticket and an authenticator for the principal "service.hostname@realm", where "service" is the service name specified in the protocol's profile, "hostname" is the first component of the host name of the server with all letters in lower case, and where "realm" is the Kerberos realm of the server. The encrypted checksum field included within the Kerberos authenticator contains the server provided challenge in network byte order.
第一个挑战由网络字节顺序的随机32位数字组成。客户端使用Kerberos票证和主体“服务”的身份验证程序进行响应。hostname@realm，其中“service”是协议配置文件中指定的服务名称，“hostname”是服务器主机名的第一个组件，所有字母都用小写字母表示，其中“realm”是服务器的Kerberos领域。Kerberos验证器中包含的加密校验和字段以网络字节顺序包含服务器提供的质询。
Upon decrypting and verifying the ticket and authenticator, the server verifies that the contained checksum field equals the original server provided random 32-bit number. Should the verification be successful, the server must add one to the checksum and construct 8 octets of data, with the first four octets containing the incremented checksum in network byte order, the fifth octet containing a bit-mask specifying the security layers supported by the server, and the sixth through eighth octets containing, in network byte order, the maximum cipher-text buffer size the server is able to receive. The server must encrypt using DES ECB mode the 8 octets of data in the session key and issue that encrypted data in a second challenge. The client considers the server authenticated if the first four octets of the un-encrypted data is equal to one plus the checksum it previously sent.
解密和验证票证和验证器后，服务器将验证包含的校验和字段是否等于原始服务器提供的随机32位数字。如果验证成功，服务器必须向校验和中添加一个，并构造8个八位字节的数据，前四个八位字节包含按网络字节顺序递增的校验和，第五个八位字节包含指定服务器支持的安全层的位掩码，第六到第八个八位字节包含，按网络字节顺序，服务器能够接收的最大密文缓冲区大小。服务器必须使用DES ECB模式加密会话密钥中的8个八位字节的数据，并在第二个质询中发出加密数据。如果未加密数据的前四个八位字节等于一加上之前发送的校验和，则客户端认为服务器已通过身份验证。
The client must construct data with the first four octets containing the original server-issued checksum in network byte order, the fifth octet containing the bit-mask specifying the selected security layer, the sixth through eighth octets containing in network byte order the maximum cipher-text buffer size the client is able to receive, and the following octets containing the authorization identity. The client must then append from one to eight zero-valued octets so that the length of the data is a multiple of eight octets. The client must then encrypt using DES PCBC mode the data with the session key and respond with the encrypted data. The server decrypts the data and verifies the contained checksum. The server must verify that the principal identified in the Kerberos ticket is authorized to connect as that authorization identity. After this verification, the authentication process is complete.
客户端必须构造数据，前四个八位字节包含原始服务器以网络字节顺序发出的校验和，第五个八位字节包含指定所选安全层的位掩码，第六到第八个八位字节包含客户端能够接收的最大密文缓冲区大小，以网络字节顺序，以及包含授权标识的以下八位字节。然后，客户机必须追加1到8个零值八位字节，以便数据的长度是8个八位字节的倍数。然后，客户端必须使用DES PCBC模式使用会话密钥对数据进行加密，并使用加密数据进行响应。服务器解密数据并验证包含的校验和。服务器必须验证Kerberos票证中标识的主体是否被授权作为该授权标识进行连接。验证后，身份验证过程完成。
The security layers and their corresponding bit-masks are as follows:
安全层及其对应的位掩码如下所示：
1 No security layer 2 Integrity (krb_mk_safe) protection 4 Privacy (krb_mk_priv) protection
1无安全层2完整性（krb_mk_安全）保护4隐私（krb_mk_priv）保护
Other bit-masks may be defined in the future; bits which are not understood must be negotiated off.
将来可以定义其他位掩码；未理解的位必须协商关闭。
EXAMPLE: The following are two Kerberos version 4 login scenarios to the IMAP4 protocol (note that the line breaks in the sample authenticators are for editorial clarity and are not in real authenticators)
示例：以下是IMAP4协议的两个Kerberos版本4登录场景（请注意，示例验证器中的换行符是为了编辑清晰，而不是真实验证器中的换行符）
S: * OK IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful
S: * OK IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful
S: * OK IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + gcfgCA==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: A001 NO Kerberos V4 authentication failed
S: * OK IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + gcfgCA==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: A001 NO Kerberos V4 authentication failed
The mechanism name associated with all mechanisms employing the GSSAPI [RFC 2078] is "GSSAPI".
与使用GSSAPI[RFC 2078]的所有机制相关联的机制名称为“GSSAPI”。
The client calls GSS_Init_sec_context, passing in 0 for input_context_handle (initially) and a 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. The client then responds with the resulting output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED,
客户端调用GSS_Init_sec_context，传入0作为输入_context_句柄（最初）和一个target_名称，该target_名称等于使用GSS_C_NT_HOSTBASED_服务的输入_name_类型调用的GSS_导入_名称的输出_名称，输入_名称字符串为“service@hostname其中“service”是协议配置文件中指定的服务名称，“hostname”是服务器的完全限定主机名。然后，客户机使用生成的输出令牌进行响应。如果GSS_Init_sec_上下文返回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_上下文的调用，重复本段中的操作。
When GSS_Init_sec_context returns GSS_S_COMPLETE, 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 to send to the server. 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, and the remaining octets containing the authorization identity. 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.
当GSS_Init_sec_context返回GSS_S_COMPLETE时，客户端将执行以下操作：如果对GSS_Init_sec_context的最后一次调用返回了输出标记，则客户端将使用输出标记进行响应，否则客户端将不响应任何数据。然后，客户机应该期望服务器在后续质询中发出令牌。客户端将此令牌传递给GSS_Unwrap，并将生成的明文的第一个八位字节解释为位掩码，指定服务器支持的安全层，第二个到第四个八位字节作为发送到服务器的最大大小输出_消息。然后，客户机构造数据，第一个八位字节包含指定所选安全层的位掩码，第二到第四个八位字节包含网络字节顺序的客户机能够接收的最大大小输出消息，其余八位字节包含授权标识。客户机将数据传递给GSS_Wrap，conf_标志设置为FALSE，并使用生成的输出_消息进行响应。然后客户端可以考虑服务器验证了。
The server passes the initial client response to GSS_Accept_sec_context as input_token, setting input_context_handle to 0 (initially). If GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED, the server returns the generated output_token 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，并将输入上下文句柄设置为0（最初）。如果GSS_Accept_sec_context返回所需的GSS_S_CONTINUE_，服务器将生成的输出_令牌返回质询中的客户端，并将结果响应传递给另一个对GSS_Accept_sec_context的调用，重复本段中的操作。
When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client 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. 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. 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 to send to the client, and the remaining
当GSS_Accept_sec_context返回GSS_sec_COMPLETE时，客户端将执行以下操作：如果对GSS_Accept_sec_context的最后一次调用返回了一个输出令牌，服务器将在质询中将其返回给客户端，并期望客户端无数据的答复。无论是否返回了输出_令牌（以及在收到客户端对该输出_令牌的任何响应后），服务器都会构造4个八位字节的数据，第一个八位组包含指定服务器支持的安全层的位掩码，第二到第四个八位组包含网络字节顺序中服务器能够接收的最大大小输出令牌。然后，服务器必须将明文传递给GSS_Wrap，conf_标志设置为FALSE，并在质询中向客户端发出生成的输出_消息。然后，服务器必须将结果响应传递给GSS_Unwrap，并将结果明文的第一个八位组解释为所选安全层的位掩码，第二到第四个八位组解释为要发送到客户端的最大大小输出_消息，其余八位组解释为
octets as the authorization identity. The server must verify that the src_name is authorized to authenticate as the authorization identity. After these verifications, the authentication process is complete.
八位字节作为授权标识。服务器必须验证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 Privacy 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 which are not understood must be negotiated off.
将来可以定义其他位掩码；未理解的位必须协商关闭。
The mechanism name associated with S/Key [RFC 1760] using the MD4 digest algorithm is "SKEY".
与使用MD4摘要算法的S/Key[RFC1760]关联的机制名为“SKEY”。
The client sends an initial response with the authorization identity.
客户端发送带有授权标识的初始响应。
The server then issues a challenge which contains the decimal sequence number followed by a single space and the seed string for the indicated authorization identity. The client responds with the one-time-password, as either a 64-bit value in network byte order or encoded in the "six English words" format.
然后，服务器发出一个质询，该质询包含十进制序列号，后跟一个空格和指定授权标识的种子字符串。客户端使用一次性密码进行响应，密码可以是网络字节顺序的64位值，也可以是“六个英文单词”格式的编码。
The server must verify the one-time-password. After this verification, the authentication process is complete.
服务器必须验证一次性密码。验证后，身份验证过程完成。
S/Key authentication does not provide for any security layers.
S/Key身份验证不提供任何安全层。
EXAMPLE: The following are two S/Key login scenarios in the IMAP4 protocol.
示例：以下是IMAP4协议中的两个S/Key登录场景。
S: * OK IMAP4 Server
C: A001 AUTHENTICATE SKEY
S: +
C: bW9yZ2Fu
S: + OTUgUWE1ODMwOA==
C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
S: A001 OK S/Key authentication successful
S: * OK IMAP4 Server
C: A001 AUTHENTICATE SKEY
S: +
C: bW9yZ2Fu
S: + OTUgUWE1ODMwOA==
C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
S: A001 OK S/Key authentication successful
S: * OK IMAP4 Server
C: A001 AUTHENTICATE SKEY
S: +
C: c21pdGg=
S: + OTUgUWE1ODMwOA==
C: BsAY3g4gBNo=
S: A001 NO S/Key authentication failed
S: * OK IMAP4 Server
C: A001 AUTHENTICATE SKEY
S: +
C: c21pdGg=
S: + OTUgUWE1ODMwOA==
C: BsAY3g4gBNo=
S: A001 NO S/Key authentication failed
The following is an S/Key login scenario in an IMAP4-like protocol which has an optional "initial response" argument to the AUTHENTICATE command.
以下是类似IMAP4的协议中的S/Key登录场景，该协议对AUTHENTICATE命令具有可选的“initial response”参数。
S: * OK IMAP4-Like Server
C: A001 AUTHENTICATE SKEY bW9yZ2Fu
S: + OTUgUWE1ODMwOA==
C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
S: A001 OK S/Key authentication successful
S: * OK IMAP4-Like Server
C: A001 AUTHENTICATE SKEY bW9yZ2Fu
S: + OTUgUWE1ODMwOA==
C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
S: A001 OK S/Key authentication successful
The mechanism name associated with external authentication is "EXTERNAL".
与外部身份验证关联的机制名称为“外部”。
The client sends an initial response with the authorization identity.
客户端发送带有授权标识的初始响应。
The server uses information, external to SASL, to determine whether the client is authorized to authenticate as the authorization identity. If the client is so authorized, the server indicates successful completion of the authentication exchange; otherwise the server indicates failure.
服务器使用SASL之外的信息来确定客户端是否被授权作为授权标识进行身份验证。如果客户机被如此授权，则服务器指示认证交换成功完成；否则，服务器指示失败。
The system providing this external information may be, for example, IPsec or TLS.
例如，提供该外部信息的系统可以是IPsec或TLS。
If the client sends the empty string as the authorization identity (thus requesting the authorization identity be derived from the client's authentication credentials), the authorization identity is to be derived from authentication credentials which exist in the system which is providing the external authentication.
如果客户端发送空字符串作为授权标识（因此请求从客户端的身份验证凭据派生授权标识），则授权标识将从提供外部身份验证的系统中存在的身份验证凭据派生。
[RFC 2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC 2060]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 2060，1996年12月。
[RFC 2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[RFC 2078]林恩，J.，“通用安全服务应用程序接口，第2版”，RFC 2078，1997年1月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，1997年3月。
[RFC 2223] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC 2223]Postel，J.和J.Reynolds，“RFC作者须知”，RFC 2223，1997年10月。
[RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC 1760, February 1995.
[RFC1760]Haller，N.，“S/键一次性密码系统”，RFC1760，1995年2月。
[RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC 1700]Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
Security issues are discussed throughout this memo.
本备忘录中讨论了安全问题。
The mechanisms that support integrity protection are designed such that the negotiation of the security layer and authorization identity is integrity protected. When the client selects a security layer with at least integrity protection, this protects against an active attacker hijacking the connection and modifying the authentication exchange to negotiate a plaintext connection.
支持完整性保护的机制的设计应确保安全层和授权标识的协商得到完整性保护。当客户端选择至少具有完整性保护的安全层时，这可以防止主动攻击者劫持连接并修改身份验证交换以协商明文连接。
When a server or client supports multiple authentication mechanisms, each of which has a different security strength, it is possible for an active attacker to cause a party to use the least secure mechanism supported. To protect against this sort of attack, a client or server which supports mechanisms of different strengths should have a configurable minimum strength that it will use. It is not sufficient for this minimum strength check to only be on the server, since an active attacker can change which mechanisms the client sees as being supported, causing the client to send authentication credentials for its weakest supported mechanism.
当服务器或客户端支持多个身份验证机制（每个机制具有不同的安全强度）时，活动攻击者可能会导致一方使用受支持的最不安全的机制。为防止此类攻击，支持不同强度机制的客户端或服务器应具有可配置的最低强度。仅在服务器上进行此最小强度检查是不够的，因为活动攻击者可以更改客户端认为受支持的机制，从而导致客户端为其最薄弱的受支持机制发送身份验证凭据。
The client's selection of a SASL mechanism is done in the clear and may be modified by an active attacker. It is important for any new SASL mechanisms to be designed such that an active attacker cannot obtain an authentication with weaker security properties by modifying the SASL mechanism name and/or the challenges and responses.
客户端对SASL机制的选择是在clear中完成的，可能会被活动攻击者修改。重要的是，任何新的SASL机制的设计应确保主动攻击者无法通过修改SASL机制名称和/或质询和响应来获得安全性较弱的身份验证。
Any protocol interactions prior to authentication are performed in the clear and may be modified by an active attacker. In the case where a client selects integrity protection, it is important that any security-sensitive protocol negotiations be performed after authentication is complete. Protocols should be designed such that negotiations performed prior to authentication should be either ignored or revalidated once authentication is complete.
身份验证之前的任何协议交互都是在clear中执行的，并且可能会被活动攻击者修改。在客户机选择完整性保护的情况下，重要的是在身份验证完成后执行任何安全敏感协议协商。协议的设计应确保在身份验证完成后，在身份验证之前执行的协商应被忽略或重新验证。
John G. Myers Netscape Communications 501 E. Middlefield Road Mail Stop MV-029 Mountain View, CA 94043-4042
约翰·G·迈尔斯·网景通讯501 E.米德尔菲尔德路邮递站MV-029加利福尼亚州山景城94043-4042
EMail: jgmyers@netscape.com
EMail: jgmyers@netscape.com
Questions have been raised about the relationship between SASL and various services (such as IPsec and TLS) which provide a secured connection.
人们对SASL与提供安全连接的各种服务（如IPsec和TLS）之间的关系提出了疑问。
Two of the key features of SASL are:
SASL的两个关键特性是：
1. The separation of the authorization identity from the identity in the client's credentials. This permits agents such as proxy servers to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying.
1. 将授权标识与客户端凭据中的标识分离。这允许代理服务器（如代理服务器）使用其自己的凭据进行身份验证，同时请求其代理的身份的访问权限。
2. Upon successful completion of an authentication exchange, the server knows the authorization identity the client wishes to use. This allows servers to move to a "user is authenticated" state in the protocol.
2. 成功完成身份验证交换后，服务器知道客户端希望使用的授权标识。这允许服务器移动到协议中的“用户已验证”状态。
These features are extremely important to some application protocols, yet Transport Security services do not always provide them. To define SASL mechanisms based on these services would be a very messy task, as the framing of these services would be redundant with the framing of SASL and some method of providing these important SASL features would have to be devised.
这些功能对于某些应用程序协议非常重要，但传输安全服务并不总是提供这些功能。基于这些服务定义SASL机制将是一项非常复杂的任务，因为这些服务的框架与SASL的框架是冗余的，必须设计一些提供这些重要SASL特性的方法。
Sometimes it is desired to enable within an existing connection the use of a security service which does not fit the SASL model. (TLS is an example of such a service.) This can be done by adding a command, for example "STARTTLS", to the protocol. Such a command is outside the scope of SASL, and should be different from the command which starts a SASL authentication protocol exchange.
有时需要在现有连接中启用不符合SASL模型的安全服务。（TLS是此类服务的一个示例。）这可以通过向协议添加命令（例如“STARTTLS”）来实现。这样的命令不在SASL的范围内，并且应该与启动SASL身份验证协议交换的命令不同。
In certain situations, it is reasonable to use SASL underneath one of these Transport Security services. The transport service would secure the connection, either service would authenticate the client, and SASL would negotiate the authorization identity. The SASL negotiation would be what moves the protocol from "unauthenticated" to "authenticated" state. The "EXTERNAL" SASL mechanism is explicitly intended to handle the case where the transport service secures the connection and authenticates the client and SASL negotiates the authorization identity.
在某些情况下，在这些交通安全服务下使用SASL是合理的。传输服务将保护连接，任何一个服务都将对客户端进行身份验证，SASL将协商授权标识。SASL协商将使协议从“未经验证”状态变为“已验证”状态。“外部”SASL机制明确用于处理传输服务保护连接并验证客户端以及SASL协商授权标识的情况。
When using SASL underneath a sufficiently strong Transport Security service, a SASL security layer would most likely be redundant. The client and server would thus probably want to negotiate off the use of a SASL security layer.
当在足够强大的传输安全服务下使用SASL时，SASL安全层很可能是冗余的。因此，客户机和服务器可能希望协商SASL安全层的使用。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
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 implmentation may be prepared, copied, published andand 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。