Network Working Group A. Melnikov, Ed.
Request for Comments: 4422 Isode Limited
Obsoletes: 2222 K. Zeilenga, Ed.
Category: Standards Track OpenLDAP Foundation
June 2006
Network Working Group A. Melnikov, Ed.
Request for Comments: 4422 Isode Limited
Obsoletes: 2222 K. Zeilenga, Ed.
Category: Standards Track OpenLDAP Foundation
June 2006
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.
简单身份验证和安全层（SASL）是一个框架，用于通过可替换机制在面向连接的协议中提供身份验证和数据安全服务。它提供了协议和机制之间的结构化接口。由此产生的框架允许新协议重用现有机制，并允许旧协议使用新机制。该框架还提供了一种协议，用于保护数据安全层内的后续协议交换。
This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.
本文档描述了SASL机制的结构，描述了协议如何包括对SASL的支持，并定义了通过连接承载数据安全层的协议。此外，本文档定义了一种SASL机制，即外部机制。
This document obsoletes RFC 2222.
本文件废除了RFC 2222。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Document Audiences .........................................4
1.2. Relationship to Other Documents ............................4
1.3. Conventions ................................................5
2. Identity Concepts ...............................................5
3. The Authentication Exchange .....................................6
3.1. Mechanism Naming ...........................................8
3.2. Mechanism Negotiation ......................................9
3.3. Request Authentication Exchange ............................9
3.4. Challenges and Responses ...................................9
3.4.1. Authorization Identity String ......................10
3.5. Aborting Authentication Exchanges .........................10
3.6. Authentication Outcome ....................................11
3.7. Security Layers ...........................................12
3.8. Multiple Authentications ..................................12
4. Protocol Requirements ..........................................13
5. Mechanism Requirements .........................................16
6. Security Considerations ........................................18
6.1. Active Attacks ............................................19
6.1.1. Hijack Attacks .....................................19
6.1.2. Downgrade Attacks ..................................19
6.1.3. Replay Attacks .....................................20
6.1.4. Truncation Attacks .................................20
6.1.5. Other Active Attacks ...............................20
6.2. Passive Attacks ...........................................20
6.3. Re-keying .................................................21
6.4. Other Considerations ......................................21
7. IANA Considerations ............................................22
7.1. SASL Mechanism Registry ...................................22
7.2. Registration Changes ......................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................27
9. Acknowledgements ...............................................28
Appendix A. The SASL EXTERNAL Mechanism ..........................29
A.1. EXTERNAL Technical Specification ..........................29
A.2. SASL EXTERNAL Examples ....................................30
A.3. Security Considerations ...................................31
Appendix B. Changes since RFC 2222 ...............................31
1. Introduction ....................................................3
1.1. Document Audiences .........................................4
1.2. Relationship to Other Documents ............................4
1.3. Conventions ................................................5
2. Identity Concepts ...............................................5
3. The Authentication Exchange .....................................6
3.1. Mechanism Naming ...........................................8
3.2. Mechanism Negotiation ......................................9
3.3. Request Authentication Exchange ............................9
3.4. Challenges and Responses ...................................9
3.4.1. Authorization Identity String ......................10
3.5. Aborting Authentication Exchanges .........................10
3.6. Authentication Outcome ....................................11
3.7. Security Layers ...........................................12
3.8. Multiple Authentications ..................................12
4. Protocol Requirements ..........................................13
5. Mechanism Requirements .........................................16
6. Security Considerations ........................................18
6.1. Active Attacks ............................................19
6.1.1. Hijack Attacks .....................................19
6.1.2. Downgrade Attacks ..................................19
6.1.3. Replay Attacks .....................................20
6.1.4. Truncation Attacks .................................20
6.1.5. Other Active Attacks ...............................20
6.2. Passive Attacks ...........................................20
6.3. Re-keying .................................................21
6.4. Other Considerations ......................................21
7. IANA Considerations ............................................22
7.1. SASL Mechanism Registry ...................................22
7.2. Registration Changes ......................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................27
9. Acknowledgements ...............................................28
Appendix A. The SASL EXTERNAL Mechanism ..........................29
A.1. EXTERNAL Technical Specification ..........................29
A.2. SASL EXTERNAL Examples ....................................30
A.3. Security Considerations ...................................31
Appendix B. Changes since RFC 2222 ...............................31
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. SASL provides a structured interface between protocols and mechanisms. SASL also provides a protocol for securing subsequent protocol exchanges within a data security layer. The data security layer can provide data integrity, data confidentiality, and other services.
简单身份验证和安全层（SASL）是一个框架，用于通过可替换机制在面向连接的协议中提供身份验证和数据安全服务。SASL提供了协议和机制之间的结构化接口。SASL还提供了一个协议，用于保护数据安全层内的后续协议交换。数据安全层可以提供数据完整性、数据机密性和其他服务。
SASL's design is intended to allow new protocols to reuse existing mechanisms without requiring redesign of the mechanisms and allows existing protocols to make use of new mechanisms without redesign of protocols.
SASL的设计旨在允许新协议重用现有机制而无需重新设计机制，并允许现有协议使用新机制而无需重新设计协议。
SASL is conceptually a framework that provides an abstraction layer between protocols and mechanisms as illustrated in the following diagram.
SASL在概念上是一个框架，它在协议和机制之间提供了一个抽象层，如下图所示。
SMTP LDAP XMPP Other protocols ...
\ | | /
\ | | /
SASL abstraction layer
/ | | \
/ | | \
EXTERNAL GSSAPI PLAIN Other mechanisms ...
SMTP LDAP XMPP Other protocols ...
\ | | /
\ | | /
SASL abstraction layer
/ | | \
/ | | \
EXTERNAL GSSAPI PLAIN Other mechanisms ...
It is through the interfaces of this abstraction layer that the framework allows any protocol to utilize any mechanism. While this layer does generally hide the particulars of protocols from mechanisms and the particulars of mechanisms from protocols, this layer does not generally hide the particulars of mechanisms from protocol implementations. For example, different mechanisms require different information to operate, some of them use password-based authentication, some of then require realm information, others make use of Kerberos tickets, certificates, etc. Also, in order to perform authorization, server implementations generally have to implement identity mapping between authentication identities, whose form is mechanism specific, and authorization identities, whose form is application protocol specific. Section 2 discusses identity concepts.
正是通过这个抽象层的接口，框架允许任何协议使用任何机制。虽然该层通常会对机制隐藏协议细节，对协议隐藏机制细节，但该层通常不会对协议实现隐藏机制细节。例如，不同的机制需要不同的信息来操作，其中一些使用基于密码的身份验证，一些则需要领域信息，其他则使用Kerberos票证、证书等。此外，为了执行授权，服务器实现通常必须实现身份验证标识（其形式特定于机制）和授权标识（其形式特定于应用程序协议）之间的身份映射。第2节讨论身份概念。
It is possible to design and implement this framework in ways that do abstract away particulars of similar mechanisms. Such a framework implementation, as well as mechanisms implementations, could be designed not only to be shared by multiple implementations of a particular protocol but to be shared by implementations of multiple protocols.
可以通过抽象类似机制的细节来设计和实现这个框架。这样的框架实现以及机制实现可以设计为不仅由特定协议的多个实现共享，而且由多个协议的实现共享。
The framework incorporates interfaces with both protocols and mechanisms in which authentication exchanges are carried out. Section 3 discusses SASL authentication exchanges.
该框架结合了与协议和机制的接口，在协议和机制中进行身份验证交换。第3节讨论SASL身份验证交换。
To use SASL, each protocol (amongst other items) provides a method for identifying which mechanism is to be used, a method for exchange of mechanism-specific server-challenges and client-responses, and a method for communicating the outcome of the authentication exchange. Section 4 discusses SASL protocol requirements.
为了使用SASL，每个协议（除其他项目外）都提供了一种用于确定要使用哪种机制的方法、一种用于交换特定于机制的服务器质询和客户端响应的方法，以及一种用于传递身份验证交换结果的方法。第4节讨论SASL协议要求。
Each SASL mechanism defines (amongst other items) a series of server-challenges and client-responses that provide authentication services and negotiate data security services. Section 5 discusses SASL mechanism requirements.
每个SASL机制（除其他项外）定义了一系列服务器挑战和客户端响应，它们提供身份验证服务和协商数据安全服务。第5节讨论SASL机制需求。
Section 6 discusses security considerations. Section 7 discusses IANA considerations. Appendix A defines the SASL EXTERNAL mechanism.
第6节讨论了安全注意事项。第7节讨论IANA注意事项。附录A定义了SASL外部机制。
This document is written to serve several different audiences:
本文件旨在为几个不同的受众服务：
- protocol designers using this specification to support authentication in their protocol,
- 协议设计者使用此规范支持其协议中的身份验证，
- mechanism designers that define new SASL mechanisms, and
- 定义新SASL机制的机制设计器，以及
- implementors of clients or servers for those protocols that support SASL.
- 支持SASL的协议的客户端或服务器的实现者。
While the document organization is intended to allow readers to focus on details relevant to their engineering, readers are encouraged to read and understand all aspects of this document.
虽然文档组织旨在让读者关注与其工程相关的细节，但鼓励读者阅读和理解本文档的各个方面。
This document obsoletes RFC 2222. It replaces all portions of RFC 2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the GSSAPI mechanism), 7.3 (the SKEY mechanism). The KERBEROS_IV and SKEY mechanisms are now viewed as obsolete and their specifications provided in RFC 2222 are Historic. The GSSAPI mechanism is now separately specified [SASL-GSSAPI].
本文件废除了RFC 2222。它取代了RFC2222的所有部分，但第7.1节（KERBEROS_IV机制）、第7.2节（GSSAPI机制）、第7.3节（SKEY机制）除外。KERBEROS_IV和SKEY机制现在被认为是过时的，RFC 2222中提供的规范具有历史意义。GSSAPI机制现在单独指定[SASL-GSSAPI]。
Appendix B provides a summary of changes since RFC 2222.
附录B提供了自RFC 2222以来的变更摘要。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中所述进行解释。
Character names in this document use the notation for code points and names from the Unicode Standard [Unicode]. For example, the letter "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
本文档中的字符名称使用Unicode标准[Unicode]中的代码点和名称表示法。例如，字母“a”可以表示为<U+0061>或<拉丁文小写字母a>。
Note: a glossary of terms used in Unicode can be found in [Glossary]. Information on the Unicode character encoding model can be found in [CharModel].
注：Unicode中使用的术语表可在[glossary]中找到。有关Unicode字符编码模型的信息可在[CharModel]中找到。
In examples, "C:" and "S:" indicate lines of data to be sent by the client and server, respectively. Lines have been wrapped for improved readability.
在示例中，“C:”和“S:”分别表示客户端和服务器要发送的数据行。为提高可读性，行已包装。
In practice, authentication and authorization may involve multiple identities, possibly in different forms (simple username, Kerberos principal, X.500 Distinguished Name, etc.), possibly with different representations (e.g., ABNF-described UTF-8 encoded Unicode character string, BER-encoded Distinguished Name). While technical specifications often prescribe both the identity form and representation used on the network, different identity forms and/or representations may be (and often are) used within implementations. How identities of different forms relate to each other is, generally, a local matter. In addition, the forms and representations used within an implementation are a local matter.
实际上，身份验证和授权可能涉及多个身份，可能以不同的形式（简单用户名、Kerberos主体、X.500可分辨名称等），可能具有不同的表示（例如，ABNF描述的UTF-8编码的Unicode字符串、BER编码的可分辨名称）。虽然技术规范通常规定了网络上使用的标识形式和表示，但在实现中可能（并且经常）使用不同的标识形式和/或表示。不同形式的身份如何相互关联，通常是一个局部问题。此外，实现中使用的形式和表示是本地事务。
However, conceptually, the SASL framework involves two identities:
然而，从概念上讲，SASL框架涉及两个身份：
1) an identity associated with the authentication credentials (termed the authentication identity), and
1) 与认证凭证关联的标识（称为认证标识），以及
2) an identity to act as (termed the authorization identity).
2) 要充当的身份（称为授权身份）。
SASL mechanism specifications describe the credential form(s) (e.g., X.509 certificates, Kerberos tickets, simple username/password) used to authenticate the client, including (where appropriate) the syntax and semantics of authentication identities carried in the credentials. SASL protocol specifications describe the identity form(s) used in authorization and, in particular, prescribe the syntax and semantics of the authorization identity character string to be transferred by mechanisms.
SASL机制规范描述了用于对客户端进行身份验证的凭证形式（例如，X.509证书、Kerberos票据、简单用户名/密码），包括（在适当情况下）凭证中携带的身份验证标识的语法和语义。SASL协议规范描述了授权中使用的标识形式，特别是规定了要通过机制传输的授权标识字符串的语法和语义。
The client provides its credentials (which include or imply an authentication identity) and, optionally, a character string representing the requested authorization identity as part of the SASL exchange. When this character string is omitted or empty, the client is requesting to act as the identity associated with the credentials (e.g., the user is requesting to act as the authentication identity).
客户端提供其凭据（包括或暗示身份验证标识）以及表示请求的授权标识的字符串（可选），作为SASL交换的一部分。当该字符串被省略或为空时，客户端请求充当与凭据关联的标识（例如，用户请求充当身份验证标识）。
The server is responsible for verifying the client's credentials and verifying that the identity it associates with the client's credentials (e.g., the authentication identity) is allowed to act as the authorization identity. A SASL exchange fails if either (or both) of these verifications fails. (The SASL exchange may fail for other reasons, such as service authorization failure.)
服务器负责验证客户端的凭据，并验证与客户端凭据关联的标识（例如，身份验证标识）是否可以用作授权标识。如果其中一个（或两个）验证失败，SASL交换将失败。（SASL exchange可能因其他原因而失败，例如服务授权失败。）
However, the precise form(s) of the authentication identities (used within the server in its verifications, or otherwise) and the precise form(s) of the authorization identities (used in making authorization decisions, or otherwise) are beyond the scope of SASL and this specification. In some circumstances, the precise identity forms used in some context outside of the SASL exchange may be dictated by other specifications. For instance, an identity assumption authorization (proxy authorization) policy specification may dictate how authentication and authorization identities are represented in policy statements.
但是，身份验证标识的精确形式（在服务器验证或其他过程中使用）和授权标识的精确形式（在做出授权决策或其他过程中使用）超出了SASL和本规范的范围。在某些情况下，SASL交换之外的某些上下文中使用的精确标识形式可能由其他规范规定。例如，身份假设授权（代理授权）策略规范可以规定如何在策略语句中表示身份验证和授权身份。
Each authentication exchange consists of a message from the client to the server requesting authentication via a particular mechanism, followed by one or more pairs of challenges from the server and responses from the client, followed by a message from the server indicating the outcome of the authentication exchange. (Note: exchanges may also be aborted as discussed in Section 3.5.)
每个身份验证交换都包括一条从客户端到服务器的消息，该消息通过特定机制请求身份验证，然后是来自服务器的一对或多对质询和来自客户端的响应，最后是来自服务器的一条消息，指示身份验证交换的结果。（注：如第3.5节所述，交换也可能中止。）
The following illustration provides a high-level overview of an authentication exchange.
下图提供了身份验证交换的高级概述。
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
If the outcome is successful and a security layer was negotiated, this layer is then installed (see Section 3.7). This also applies to the following illustrations.
如果结果成功并协商了安全层，则安装该层（见第3.7节）。这也适用于以下插图。
Some mechanisms specify that the first data sent in the authentication exchange is from the client to the server. Protocols may provide an optional initial response field in the request message to carry this data. Where the mechanism specifies that the first data sent in the exchange is from the client to the server, the protocol provides an optional initial response field, and the client uses this field, the exchange is shortened by one round-trip:
某些机制指定在身份验证交换中发送的第一个数据是从客户端发送到服务器的。协议可以在请求消息中提供一个可选的初始响应字段来携带该数据。当机制指定在交换中发送的第一个数据是从客户端发送到服务器时，协议提供可选的初始响应字段，客户端使用此字段，交换将缩短一个往返行程：
C: Request authentication exchange + Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
C: Request authentication exchange + Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
Where the mechanism specifies that the first data sent in the exchange is from the client to the server and this field is unavailable or unused, the client request is followed by an empty challenge.
如果该机制指定在exchange中发送的第一个数据是从客户端发送到服务器的，并且此字段不可用或未使用，则客户端请求后面会有一个空质询。
C: Request authentication exchange
S: Empty Challenge
C: Initial Response
<additional challenge/response messages>
S: Outcome of authentication exchange
C: Request authentication exchange
S: Empty Challenge
C: Initial Response
<additional challenge/response messages>
S: Outcome of authentication exchange
Should a client include an initial response in its request where the mechanism does not allow the client to send data first, the authentication exchange fails.
如果客户端在其请求中包含初始响应，而该机制不允许客户端首先发送数据，则身份验证交换将失败。
Some mechanisms specify that the server is to send additional data to the client when indicating a successful outcome. Protocols may provide an optional additional data field in the outcome message to carry this data. Where the mechanism specifies that the server is to return additional data with the successful outcome, the protocol provides an optional additional data field in the outcome message, and the server uses this field, the exchange is shortened by one round-trip:
某些机制指定服务器在指示成功结果时向客户端发送额外数据。协议可以在结果消息中提供可选的附加数据字段来携带该数据。如果该机制指定服务器返回具有成功结果的附加数据，则协议在结果消息中提供可选的附加数据字段，并且服务器使用该字段，则交换将缩短一个往返时间：
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange with
additional data with success
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange with
additional data with success
Where the mechanism specifies that the server is to return additional data to the client with a successful outcome and this field is unavailable or unused, the additional data is sent as a challenge whose response is empty. After receiving this response, the server then indicates the successful outcome.
如果该机制指定服务器将向客户端返回附加数据并获得成功结果，并且此字段不可用或未使用，则附加数据将作为响应为空的质询发送。收到此响应后，服务器将指示成功的结果。
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Additional data challenge
C: Empty Response
S: Outcome of authentication exchange
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Additional data challenge
C: Empty Response
S: Outcome of authentication exchange
Where mechanisms specify that the first data sent in the exchange is from the client to the server and additional data is sent to the client along with indicating a successful outcome, and the protocol provides fields supporting both, then the exchange takes two fewer round-trips:
如果机制指定在exchange中发送的第一个数据是从客户端发送到服务器的，并将其他数据发送到客户端，同时指示成功的结果，并且协议提供了支持这两种结果的字段，那么exchange将少走两条往返路线：
C: Request authentication exchange + Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
with additional data with success
C: Request authentication exchange + Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
with additional data with success
instead of:
而不是：
C: Request authentication exchange
S: Empty Challenge
C: Initial Response
<additional challenge/response messages>
S: Additional data challenge
C: Empty Response
S: Outcome of authentication exchange
C: Request authentication exchange
S: Empty Challenge
C: Initial Response
<additional challenge/response messages>
S: Additional data challenge
C: Empty Response
S: Outcome of authentication exchange
SASL mechanisms are named by character strings, from 1 to 20 characters in length, consisting of ASCII [ASCII] uppercase letters, digits, hyphens, and/or underscores. In the following Augmented Backus-Naur Form (ABNF) [RFC4234] grammar, the <sasl-mech> production defines the syntax of a SASL mechanism name.
SASL机制由字符串命名，长度从1到20个字符，由ASCII[ASCII]大写字母、数字、连字符和/或下划线组成。在以下扩展的Backus-Naur Form（ABNF）[RFC4234]语法中，<sasl-mech>产品定义了sasl机制名称的语法。
sasl-mech = 1*20mech-char
mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _
; from ASCII character set.
sasl-mech = 1*20mech-char
mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _
; from ASCII character set.
UPPER-ALPHA = %x41-5A ; A-Z (uppercase only)
DIGIT = %x30-39 ; 0-9
HYPHEN = %x2D ; hyphen (-)
UNDERSCORE = %x5F ; underscore (_)
UPPER-ALPHA = %x41-5A ; A-Z (uppercase only)
DIGIT = %x30-39 ; 0-9
HYPHEN = %x2D ; hyphen (-)
UNDERSCORE = %x5F ; underscore (_)
SASL mechanism names are registered as discussed in Section 7.1.
SASL机制名称按照第7.1节所述进行注册。
Mechanism negotiation is protocol specific.
协商机制是特定于协议的。
Commonly, a protocol will specify that the server advertises supported and available mechanisms to the client via some facility provided by the protocol, and the client will then select the "best" mechanism from this list that it supports and finds suitable.
通常，协议将指定服务器通过协议提供的某些设施向客户机播发受支持和可用的机制，然后客户机将从此列表中选择其支持并认为合适的“最佳”机制。
Note that the mechanism negotiation is not protected by the subsequent authentication exchange and hence is subject to downgrade attacks if not protected by other means.
请注意，协商机制不受后续身份验证交换的保护，因此，如果不通过其他方式进行保护，则会受到降级攻击。
To detect downgrade attacks, a protocol can allow the client to discover available mechanisms subsequent to the authentication exchange and installation of data security layers with at least data integrity protection. This allows the client to detect changes to the list of mechanisms supported by the server.
为了检测降级攻击，协议允许客户端在身份验证交换和数据安全层安装之后发现可用的机制，至少具有数据完整性保护。这允许客户端检测对服务器支持的机制列表的更改。
The authentication exchange is initiated by the client by requesting authentication via a mechanism it specifies. The client sends a message that contains the name of the mechanism to the server. The particulars of the message are protocol specific.
身份验证交换由客户端通过其指定的机制请求身份验证来启动。客户端向服务器发送一条包含机制名称的消息。消息的详细信息是特定于协议的。
Note that the name of the mechanism is not protected by the mechanism, and hence is subject to alteration by an attacker if not integrity protected by other means.
请注意，该机制不保护该机制的名称，因此，如果未通过其他方式保护完整性，攻击者可能会更改该机制的名称。
Where the mechanism is defined to allow the client to send data first, and the protocol's request message includes an optional initial response field, the client may include the response to the initial challenge in the authentication request message.
在机制被定义为允许客户端首先发送数据，并且协议的请求消息包括可选的初始响应字段的情况下，客户端可以在认证请求消息中包括对初始质询的响应。
The authentication exchange involves one or more pairs of server-challenges and client-responses, the particulars of which are mechanism specific. These challenges and responses are enclosed in protocol messages, the particulars of which are protocol specific.
身份验证交换涉及一对或多对服务器质询和客户端响应，其细节是特定于机制的。这些挑战和响应包含在协议消息中，协议消息的细节是特定于协议的。
Through these challenges and responses, the mechanism may:
通过这些挑战和应对措施，该机制可以：
- authenticate the client to the server,
- 向服务器验证客户端，
- authenticate the server to the client,
- 向客户端验证服务器，
- transfer an authorization identity string,
- 传输授权标识字符串，
- negotiate a security layer, and
- 协商安全层，以及
- provide other services.
- 提供其他服务。
The negotiation of the security layer may involve negotiation of the security services to be provided in the layer, how these services will be provided, and negotiation of a maximum cipher-text buffer size each side is able to receive in the layer (see Section 3.6).
安全层的协商可能涉及在该层中提供的安全服务的协商，这些服务将如何提供，以及各方能够在该层中接收的最大密文缓冲区大小的协商（见第3.6节）。
After receiving an authentication request or any client response, the server may issue a challenge, abort the exchange, or indicate the outcome of an exchange. After receiving a challenge, a client mechanism may issue a response or abort the exchange.
在接收到身份验证请求或任何客户端响应后，服务器可能会发出质询、中止交换或指示交换的结果。收到质询后，客户端机制可能会发出响应或中止交换。
The authorization identity string is a sequence of zero or more Unicode [Unicode] characters, excluding the NUL (U+0000) character, representing the identity to act as.
授权标识字符串是零个或多个Unicode[Unicode]字符的序列，不包括表示要充当身份的NUL（U+0000）字符。
If the authorization identity string is absent, the client is requesting to act as the identity the server associates with the client's credentials. An empty string is equivalent to an absent authorization identity.
如果缺少授权标识字符串，则客户端请求充当服务器与客户端凭据关联的标识。空字符串相当于缺少授权标识。
A non-empty authorization identity string indicates that the client wishes to act as the identity represented by the string. In this case, the form of identity represented by the string, as well as the precise syntax and semantics of the string, is protocol specific.
非空的授权标识字符串表示客户端希望充当该字符串表示的标识。在本例中，由字符串表示的标识形式以及字符串的精确语法和语义是特定于协议的。
While the character encoding schema used to transfer the authorization identity string in the authentication exchange is mechanism specific, mechanisms are expected to be capable of carrying the entire Unicode repertoire (with the exception of the NUL character).
虽然用于在身份验证交换中传输授权标识字符串的字符编码模式是特定于机制的，但机制应能够承载整个Unicode指令集（NUL字符除外）。
A client or server may desire to abort an authentication exchange if it is unwilling or unable to continue (or enter into).
如果客户端或服务器不愿意或无法继续（或进入），则可能希望中止身份验证交换。
A client may abort the authentication exchange by sending a message, the particulars of which are protocol specific, to the server, indicating that the exchange is aborted. The server may be required by the protocol to return a message in response to the client's abort message.
客户端可以通过向服务器发送一条消息来中止身份验证交换，该消息的细节是协议特定的，指示交换中止。协议可能要求服务器返回消息以响应客户端的中止消息。
Likewise, a server may abort the authentication exchange by sending a message, the particulars of which are protocol specific, to the client, indicating that the exchange is aborted.
类似地，服务器可以通过向客户端发送消息来中止身份验证交换，该消息的细节是特定于协议的，指示交换中止。
At the conclusion of the authentication exchange, the server sends a message, the particulars of which are protocol specific, to the client indicating the outcome of the exchange.
在身份验证交换结束时，服务器向客户端发送一条消息，该消息的详细信息是特定于协议的，指示交换的结果。
The outcome is not successful if
如果
- the authentication exchange failed for any reason,
- 身份验证交换因任何原因失败，
- the client's credentials could not be verified,
- 无法验证客户端的凭据，
- the server cannot associate an identity with the client's credentials,
- 服务器无法将标识与客户端的凭据相关联，
- the client-provided authorization identity string is malformed,
- 客户端提供的授权标识字符串格式不正确，
- the identity associated with the client's credentials is not authorized to act as the requested authorization identity,
- 与客户端凭据关联的标识未被授权作为请求的授权标识，
- the negotiated security layer (or lack thereof) is not suitable, or
- 协商的安全层（或缺少）不合适，或
- the server is not willing to provide service to the client for any reason.
- 服务器不愿意出于任何原因向客户端提供服务。
The protocol may include an optional additional data field in this outcome message. This field can only include additional data when the outcome is successful.
协议可在此结果消息中包括可选的附加数据字段。此字段只能在结果成功时包含其他数据。
If the outcome is successful and a security layer was negotiated, this layer is then installed. If the outcome is unsuccessful, or a security layer was not negotiated, any existing security is left in place.
如果结果成功并且协商了安全层，则安装该层。如果结果不成功，或者未协商安全层，则任何现有安全性都将保留。
The outcome message provided by the server can provide a way for the client to distinguish between errors that are best dealt with by re-prompting the user for her credentials, errors that are best dealt with by telling the user to try again later, and errors where the user must contact a system administrator for resolution (see the SYS and AUTH POP Response Codes [RFC3206] specification for an example). This distinction is particularly useful during scheduled server maintenance periods as it reduces support costs. It is also important that the server can be configured such that the outcome
服务器提供的结果消息可以为客户端提供一种方法，用于区分通过重新提示用户提供凭据来最好地处理的错误、通过告诉用户稍后重试来最好地处理的错误以及用户必须联系系统管理员以解决的错误（有关示例，请参阅SYS和AUTH POP响应代码[RFC3206]规范）。这种区别在计划的服务器维护期间特别有用，因为它可以降低支持成本。服务器的配置也很重要，以便
message will not distinguish between a valid user with invalid credentials and an invalid user.
消息不会区分凭据无效的有效用户和无效用户。
SASL mechanisms may offer a wide range of services in security layers. Typical services include data integrity and data confidentiality. SASL mechanisms that do not provide a security layer are treated as negotiating no security layer.
SASL机制可以在安全层中提供广泛的服务。典型的服务包括数据完整性和数据保密性。不提供安全层的SASL机制被视为无安全层。
If use of a security layer is negotiated in the authentication protocol exchange, the layer is installed by the server after indicating the outcome of the authentication exchange and installed by the client upon receipt of the outcome indication. In both cases, the layer is installed before transfer of further protocol data. The precise position upon which the layer takes effect in the protocol data stream is protocol specific.
如果在身份验证协议交换中协商使用安全层，则服务器在指示身份验证交换的结果后安装该层，客户端在收到结果指示后安装该层。在这两种情况下，在传输进一步的协议数据之前安装该层。层在协议数据流中生效的精确位置是特定于协议的。
Once the security layer is in effect in the protocol data stream, it remains in effect until either a subsequently negotiated security layer is installed or the underlying transport connection is closed.
一旦安全层在协议数据流中生效，它将保持有效，直到随后协商的安全层安装完毕或基础传输连接关闭。
When in effect, the security layer processes protocol data into buffers of protected data. If at any time the security layer is unable or unwilling to continue producing buffers protecting protocol data, the underlying transport connection MUST be closed. If the security layer is not able to decode a received buffer, the underlying connection MUST be closed. In both cases, the underlying transport connection SHOULD be closed gracefully.
有效时，安全层将协议数据处理到受保护数据的缓冲区中。如果安全层在任何时候都无法或不愿意继续生成保护协议数据的缓冲区，则必须关闭底层传输连接。如果安全层无法解码接收到的缓冲区，则必须关闭底层连接。在这两种情况下，底层传输连接都应该正常关闭。
Each buffer of protected data is transferred over the underlying transport connection as a sequence of octets prepended with a four-octet field in network byte order that represents the length of the buffer. The length of the protected data buffer MUST be no larger than the maximum size that the other side expects. Upon the receipt of a length field whose value is greater than the maximum size, the receiver SHOULD close the connection, as this might be a sign of an attack.
受保护数据的每个缓冲区在底层传输连接上传输为一个八位字节序列，该序列前面有一个表示缓冲区长度的网络字节顺序的四个八位字节字段。受保护数据缓冲区的长度不得大于另一方期望的最大大小。在收到值大于最大大小的长度字段后，接收方应关闭连接，因为这可能是攻击的迹象。
The maximum size that each side expects is fixed by the mechanism, either through negotiation or by its specification.
各方期望的最大尺寸由机构通过协商或其规格确定。
Unless explicitly permitted in the protocol (as stated in the protocol's technical specification), only one successful SASL authentication exchange may occur in a protocol session. In this
除非协议中明确允许（如协议的技术规范中所述），否则在协议会话中只能发生一次成功的SASL身份验证交换。在这个
case, once an authentication exchange has successfully completed, further attempts to initiate an authentication exchange fail.
在这种情况下，一旦身份验证交换成功完成，启动身份验证交换的进一步尝试将失败。
Where multiple successful SASL authentication exchanges are permitted in the protocol, then in no case may multiple SASL security layers be simultaneously 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. If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer remains in effect.
如果协议中允许多个成功的SASL身份验证交换，则在任何情况下，多个SASL安全层都不得同时生效。如果安全层生效，并且后续SASL协商选择第二个安全层，则第二个安全层将替换第一个安全层。如果某个安全层有效，并且后续SASL协商未选择任何安全层，则原始安全层仍有效。
Where multiple successful SASL negotiations are permitted in the protocol, the effect of a failed SASL authentication exchange upon the previously established authentication and authorization state is protocol specific. The protocol's technical specification should be consulted to determine whether the previous authentication and authorization state remains in force, or changed to an anonymous state, or otherwise was affected. Regardless of the protocol-specific effect upon previously established authentication and authorization state, the previously negotiated security layer remains in effect.
当协议中允许多次成功的SASL协商时，失败的SASL身份验证交换对先前建立的身份验证和授权状态的影响是特定于协议的。应参考协议的技术规范，以确定以前的身份验证和授权状态是否仍然有效，或是否更改为匿名状态，或是否受到影响。无论协议对先前建立的身份验证和授权状态的特定影响如何，先前协商的安全层仍然有效。
In order for a protocol to offer SASL services, its specification MUST supply the following information:
为了使协议提供SASL服务，其规范必须提供以下信息：
1) A service name, to be selected from registry of "service" elements for the Generic Security Service Application Program Interface (GSSAPI) host-based service name form, as described in Section 4.1 of [RFC2743]. Note that this registry is shared by all GSSAPI and SASL mechanisms.
1) 服务名称，从通用安全服务应用程序接口（GSSAPI）基于主机的服务名称表的“服务”元素注册表中选择，如[RFC2743]第4.1节所述。请注意，此注册表由所有GSSAPI和SASL机制共享。
2) Detail any mechanism negotiation facility that the protocol provides (see Section 3.2).
2) 详细说明协议提供的任何机制协商设施（见第3.2节）。
A protocol SHOULD specify a facility through which the client may discover, both before initiation of the SASL exchange and after installing security layers negotiated by the exchange, the names of the SASL mechanisms that the server makes available to the client. The latter is important to allow the client to detect downgrade attacks. This facility is typically provided through the protocol's extensions or capabilities discovery facility.
协议应指定一个设施，在启动SASL exchange之前和安装由exchange协商的安全层之后，客户端可通过该设施发现服务器向客户端提供的SASL机制的名称。后者对于允许客户端检测降级攻击非常重要。此功能通常通过协议的扩展或功能发现功能提供。
3) Definition of the messages necessary for authentication exchange, including the following:
3) 身份验证交换所需消息的定义，包括以下内容：
a) A message to initiate the authentication exchange (see Section 3.3).
a) 启动身份验证交换的消息（见第3.3节）。
This message MUST contain a field for carrying the name of the mechanism selected by the client.
此消息必须包含一个字段，用于承载客户端所选机制的名称。
This message SHOULD contain an optional field for carrying an initial response. If the message is defined with this field, the specification MUST describe how messages with an empty initial response are distinguished from messages with no initial response. This field MUST be capable of carrying arbitrary sequences of octets (including zero-length sequences and sequences containing zero-valued octets).
此消息应包含用于承载初始响应的可选字段。如果消息是使用此字段定义的，则规范必须描述具有空初始响应的消息与没有初始响应的消息的区别。该字段必须能够承载任意八位字节序列（包括零长度序列和包含零值八位字节的序列）。
b) Messages to transfer server challenges and client responses (see Section 3.4).
b) 传输服务器挑战和客户端响应的消息（参见第3.4节）。
Each of these messages MUST be capable of carrying arbitrary sequences of octets (including zero-length sequences and sequences containing zero-valued octets).
这些消息中的每一条都必须能够承载任意八位字节序列（包括零长度序列和包含零值八位字节的序列）。
c) A message to indicate the outcome of the authentication exchange (see Section 3.6).
c) 指示身份验证交换结果的消息（参见第3.6节）。
This message SHOULD contain an optional field for carrying additional data with a successful outcome. If the message is defined with this field, the specification MUST describe how messages with an empty additional data are distinguished from messages with no additional data. This field MUST be capable of carrying arbitrary sequences of octets (including zero-length sequences and sequences containing zero-valued octets).
此消息应包含一个可选字段，用于承载具有成功结果的其他数据。如果消息是用此字段定义的，则规范必须描述如何将具有空附加数据的消息与没有附加数据的消息区分开来。该字段必须能够承载任意八位字节序列（包括零长度序列和包含零值八位字节的序列）。
4) Prescribe the syntax and semantics of non-empty authorization identity strings (see Section 3.4.1).
4) 规定非空授权标识字符串的语法和语义（见第3.4.1节）。
In order to avoid interoperability problems due to differing normalizations, the protocol specification MUST detail precisely how and where (client or server) non-empty authorization identity strings are prepared, including all normalizations, for comparison and other applicable functions to ensure proper function.
为了避免由于不同规范化而导致的互操作性问题，协议规范必须准确地详细说明如何以及在何处（客户端或服务器）准备非空授权标识字符串，包括所有规范化，以便进行比较和其他适用功能，以确保功能正常。
Specifications are encouraged to prescribe use of existing authorization identity forms as well as existing string representations, such as simple user names [RFC4013].
鼓励规范规定使用现有授权标识表单以及现有字符串表示，如简单用户名[RFC4013]。
Where the specification does not precisely prescribe how identities in SASL relate to identities used elsewhere in the protocol, for instance, in access control policy statements, it
如果规范没有明确规定SASL中的标识与协议中其他地方使用的标识（例如，在访问控制策略语句中）的关系，那么
may be appropriate for the protocol to provide a facility by which the client can discover information (such as the representation of the identity used in making access control decisions) about established identities for these uses.
可能适合于协议提供一种设施，通过该设施，客户端可以发现关于这些用途的已建立身份的信息（例如，在作出访问控制决策时使用的身份的表示）。
5) Detail any facility the protocol provides that allows the client and/or server to abort authentication exchange (see Section 3.5).
5) 详细说明协议提供的允许客户端和/或服务器中止身份验证交换的任何设施（参见第3.5节）。
Protocols that support multiple authentications typically allow a client to abort an ongoing authentication exchange by initiating a new authentication exchange. Protocols that do not support multiple authentications may require the client to close the connection and start over to abort an ongoing authentication exchange.
支持多个身份验证的协议通常允许客户端通过启动新的身份验证交换来中止正在进行的身份验证交换。不支持多重身份验证的协议可能要求客户端关闭连接并重新启动以中止正在进行的身份验证交换。
Protocols typically allow the server to abort ongoing authentication exchanges by returning a non-successful outcome message.
协议通常允许服务器通过返回不成功的结果消息来中止正在进行的身份验证交换。
6) Identify precisely where newly negotiated security layers start to take effect, in both directions (see Section 3.7).
6) 从两个方向准确确定新协商的安全层开始生效的位置（见第3.7节）。
Typically, specifications require security layers to start taking effect on the first octet following the outcome message in data being sent by the server and on the first octet sent after receipt of the outcome message in data being sent by the client.
通常，规范要求安全层在服务器发送的数据中的结果消息之后的第一个八位组上以及在客户端发送的数据中接收到结果消息之后发送的第一个八位组上开始生效。
7) If the protocol supports other layered security services, such as Transport Layer Security (TLS) [RFC4346], the specification MUST prescribe the order in which security layers are applied to protocol data.
7) 如果协议支持其他分层安全服务，如传输层安全（TLS）[RFC4346]，则规范必须规定安全层应用于协议数据的顺序。
For instance, where a protocol supports both TLS and SASL security layers, the specification could prescribe any of the following:
例如，当协议同时支持TLS和SASL安全层时，规范可以规定以下任何一种：
a) SASL security layer is always applied first to data being sent and, hence, applied last to received data,
a) SASL安全层始终首先应用于发送的数据，因此最后应用于接收的数据，
b) SASL security layer is always applied last to data being sent and, hence, applied first to received data,
b) SASL安全层始终最后应用于发送的数据，因此首先应用于接收的数据，
c) Layers are applied in the order in which they were installed,
c) 按安装顺序应用图层，
d) Layers are applied in the reverse order in which they were installed, or
d) 按与安装相反的顺序应用图层，或
e) Both TLS and SASL security layers cannot be installed.
e) 无法安装TLS和SASL安全层。
8) Indicate whether the protocol supports multiple authentications (see Section 3.8). If so, the protocol MUST detail the effect a failed SASL authentication exchange will have upon a previously established authentication and authorization state.
8) 说明协议是否支持多重身份验证（见第3.8节）。如果是这样，协议必须详细说明失败的SASL身份验证交换对先前建立的身份验证和授权状态的影响。
Protocol specifications SHOULD avoid stating implementation requirements that would hinder replacement of applicable mechanisms. In general, protocol specifications SHOULD be mechanism neutral. There are a number of reasonable exceptions to this recommendation, including
协议规范应避免说明可能妨碍替换适用机制的实施要求。一般来说，协议规范应该是机制中立的。本建议有许多合理的例外情况，包括
- detailing how credentials (which are mechanism specific) are managed in the protocol,
- 详细说明如何在协议中管理凭据（特定于机制），
- detailing how authentication identities (which are mechanism specific) and authorization identities (which are protocol specific) relate to each other, and
- 详细说明身份验证标识（特定于机制）和授权标识（特定于协议）如何相互关联，以及
- detailing which mechanisms are applicable to the protocol.
- 详细说明哪些机制适用于协议。
SASL mechanism specifications MUST supply the following information:
SASL机构规范必须提供以下信息：
1) The name of the mechanism (see Section 3.1). This name MUST be registered as discussed in Section 7.1.
1) 机构名称（见第3.1节）。该名称必须按照第7.1节所述进行注册。
2) A definition of the server-challenges and client-responses of the authentication exchange, as well as the following:
2) 身份验证交换的服务器挑战和客户端响应的定义，以及以下内容：
a) An indication of whether the mechanism is client-first, variable, or server-first. If a SASL mechanism is defined as client-first and the client does not send an initial response in the authentication request, then the first server challenge MUST be empty (the EXTERNAL mechanism is an example of this case). If a SASL mechanism is defined as variable, then the specification needs to state how the server behaves when the initial client response in the authentication request is omitted (the DIGEST-MD5 mechanism [DIGEST-MD5] is an example of this case). If a SASL mechanism is defined as server-first, then the client MUST NOT send an initial client response in the authentication request (the CRAM-MD5 mechanism [CRAM-MD5] is an example of this case).
a) 指示机制是客户机优先、变量优先还是服务器优先。如果SASL机制定义为“客户机优先”，并且客户机未在身份验证请求中发送初始响应，则第一个服务器质询必须为空（外部机制就是这种情况的一个示例）。如果将SASL机制定义为变量，则规范需要说明在省略身份验证请求中的初始客户端响应时服务器的行为（DIGEST-MD5机制[DIGEST-MD5]就是这种情况的一个示例）。如果先将SASL机制定义为服务器，则客户端不得在身份验证请求中发送初始客户端响应（CRAM-MD5机制[CRAM-MD5]就是这种情况的一个示例）。
b) An indication of whether the server is expected to provide additional data when indicating a successful outcome. If so, if the server sends the additional data as a challenge, the
b) 指示服务器在指示成功结果时是否需要提供附加数据。如果是，如果服务器将附加数据作为质询发送，则
specification MUST indicate that the response to this challenge is an empty response.
规范必须指明对此质询的响应是空响应。
SASL mechanisms SHOULD be designed to minimize the number of challenges and responses necessary to complete the exchange.
SASL机制的设计应尽量减少完成交换所需的挑战和响应数量。
3) An indication of whether the mechanism is capable of transferring authorization identity strings (see Section 3.4.1). While some legacy mechanisms are incapable of transmitting an authorization identity (which means that for these mechanisms, the authorization identity is always the empty string), newly defined mechanisms SHOULD be capable of transferring authorization identity strings. The mechanism SHOULD NOT be capable of transferring both no authorization identity string and an empty authorization identity.
3) 机制是否能够传输授权标识字符串的指示（见第3.4.1节）。虽然一些遗留机制无法传输授权标识（这意味着对于这些机制，授权标识始终是空字符串），但新定义的机制应该能够传输授权标识字符串。该机制不能同时传输无授权标识字符串和空授权标识。
Mechanisms that are capable of transferring an authorization identity string MUST be capable of transferring arbitrary non-empty sequences of Unicode characters, excluding those that contain the NUL (U+0000) character. Mechanisms SHOULD use the UTF-8 [RFC3629] transformation format. The specification MUST detail how any Unicode code points special to the mechanism that might appear in the authorization identity string are escaped to avoid ambiguity during decoding of the authorization identity string. Typically, mechanisms that have special characters require these special characters to be escaped or encoded in the character string (after encoding it in a particular Unicode transformation format) using a data encoding scheme such as Base64 [RFC3548].
能够传输授权标识字符串的机制必须能够传输任意非空的Unicode字符序列，不包括包含NUL（U+0000）字符的序列。机制应使用UTF-8[RFC3629]转换格式。规范必须详细说明如何转义授权标识字符串中可能出现的机制专用的任何Unicode代码点，以避免在解码授权标识字符串期间出现歧义。通常，具有特殊字符的机制要求使用数据编码方案（如Base64[RFC3548]）将这些特殊字符转义或编码到字符串中（以特定的Unicode转换格式编码后）。
4) The specification MUST detail whether the mechanism offers a security layer. If the mechanism does, the specification MUST detail the security and other services offered in the layer as well as how these services are to be implemented.
4) 规范必须详细说明该机制是否提供安全层。如果机制需要，规范必须详细说明层中提供的安全性和其他服务，以及如何实现这些服务。
5) If the underlying cryptographic technology used by a mechanism supports data integrity, then the mechanism specification MUST integrity protect the transmission of an authorization identity and the negotiation of the security layer.
5) 如果机制使用的底层加密技术支持数据完整性，那么机制规范必须完整性保护授权标识的传输和安全层的协商。
SASL mechanisms SHOULD be protocol neutral.
SASL机制应该是协议中立的。
SASL mechanisms SHOULD reuse existing credential and identity forms, as well as associated syntaxes and semantics.
SASL机制应该重用现有的凭证和身份表单，以及相关的语法和语义。
SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629] for encoding Unicode [Unicode] code points for transfer.
SASL机制应使用UTF-8转换格式[RFC3629]对传输的Unicode[Unicode]码点进行编码。
In order to avoid interoperability problems due to differing normalizations, when a mechanism calls for character data (other than the authorization identity string) to be used as input to a cryptographic and/or comparison function, the specification MUST detail precisely how and where (client or server) the character data is to be prepared, including all normalizations, for input into the function to ensure proper operation.
为了避免由于不同规范化而导致的互操作性问题，当机制要求将字符数据（授权标识字符串除外）用作加密和/或比较函数的输入时，规范必须准确地详细说明字符数据的准备方式和位置（客户机或服务器），包括所有规范化，用于输入函数，以确保正确操作。
For simple user names and/or passwords in authentication credentials, SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation algorithm), SHOULD be specified as the preparation algorithm.
对于身份验证凭据中的简单用户名和/或密码，应将SASLprep[RFC4013]（StringPrep[RFC3454]准备算法的配置文件）指定为准备算法。
The mechanism SHOULD NOT use the authorization identity string in generation of any long-term cryptographic keys or hashes as there is no requirement that the authorization identity string be canonical. Long-term, here, means a term longer than the duration of the authentication exchange in which they were generated. That is, as different clients (of the same or different protocol) may provide different authorization identity strings that are semantically equivalent, use of authorization identity strings in generation of cryptographic keys and hashes will likely lead to interoperability and other problems.
该机制不应在生成任何长期加密密钥或散列时使用授权标识字符串，因为不要求授权标识字符串是规范的。在这里，长期是指比生成它们的身份验证交换的持续时间更长的期限。也就是说，由于不同的客户端（相同或不同的协议）可能提供语义等效的不同授权标识字符串，因此在生成加密密钥和散列时使用授权标识字符串可能会导致互操作性和其他问题。
Security issues are discussed throughout this memo.
本备忘录中讨论了安全问题。
Many existing SASL mechanisms do not provide adequate protection against passive attacks, let alone active attacks, in the authentication exchange. Many existing SASL mechanisms do not offer security layers. It is hoped that future SASL mechanisms will provide strong protection against passive and active attacks in the authentication exchange, as well as security layers with strong basic data security features (e.g., data integrity and data confidentiality) services. It is also hoped that future mechanisms will provide more advanced data security services like re-keying (see Section 6.3).
在身份验证交换中，许多现有的SASL机制都不能提供足够的保护来抵御被动攻击，更不用说主动攻击了。许多现有的SASL机制不提供安全层。希望未来的SASL机制能够提供强大的保护，防止身份验证交换中的被动和主动攻击，以及具有强大基本数据安全功能（如数据完整性和数据机密性）服务的安全层。还希望未来的机制将提供更高级的数据安全服务，如重新设置密钥（见第6.3节）。
Regardless, the SASL framework is susceptible to downgrade attacks. Section 6.1.2 offers a variety of approaches for preventing or detecting these attacks. In some cases, it is appropriate to use data integrity protective services external to SASL (e.g., TLS) to protect against downgrade attacks in SASL. Use of external protective security services is also important when the mechanisms available do not themselves offer adequate integrity and/or confidentiality protection of the authentication exchange and/or protocol data.
无论如何，SASL框架容易受到降级攻击。第6.1.2节提供了各种防止或检测这些攻击的方法。在某些情况下，可以使用SASL外部的数据完整性保护服务（例如TLS）来防止SASL中的降级攻击。当可用机制本身不能为认证交换和/或协议数据提供足够的完整性和/或机密性保护时，使用外部保护安全服务也很重要。
When the client selects a SASL security layer with at least integrity protection, this protection serves as a counter-measure against an active attacker hijacking the connection and modifying protocol data sent after establishment of the security layer. Implementations SHOULD close the connection when the security services in a SASL security layer report protocol data report lack of data integrity.
当客户端选择至少具有完整性保护的SASL安全层时，该保护可作为对抗主动攻击者劫持连接和修改安全层建立后发送的协议数据的一种措施。当SASL安全层中的安全服务报告协议数据缺乏数据完整性时，实现应关闭连接。
It is important that any security-sensitive protocol negotiations be performed after installation of a security layer with data integrity protection. Protocols should be designed such that negotiations performed prior to this installation should be revalidated after installation is complete. Negotiation of the SASL mechanism is security sensitive.
重要的是，在安装具有数据完整性保护的安全层之后，必须执行任何安全敏感协议协商。协议的设计应确保在此安装之前执行的协商应在安装完成后重新验证。SASL机制的协商是安全敏感的。
When a client negotiates the authentication mechanism with the server and/or other security features, it is possible for an active attacker to cause a party to use the least secure security services available. For instance, an attacker can modify the server-advertised mechanism list or can modify the client-advertised security feature list within a mechanism response. To protect against this sort of attack, implementations SHOULD NOT advertise mechanisms and/or features that cannot meet their minimum security requirements, SHOULD NOT enter into or continue authentication exchanges that cannot meet their minimum security requirements, and SHOULD verify that completed authentication exchanges result in security services that meet their minimum security requirements. Note that each endpoint needs to independently verify that its security requirements are met.
当客户端与服务器和/或其他安全功能协商身份验证机制时，活动攻击者可能会导致一方使用最不安全的可用安全服务。例如，攻击者可以修改服务器播发的机制列表，也可以在机制响应中修改客户端播发的安全功能列表。为防止此类攻击，实现不应公布无法满足其最低安全要求的机制和/或功能，不应进入或继续无法满足其最低安全要求的身份验证交换，并应验证完成的身份验证交换是否产生满足其最低安全要求的安全服务。请注意，每个端点都需要独立地验证是否满足其安全性要求。
In order to detect downgrade attacks to the least (or less) secure mechanism supported, the client can discover the SASL mechanisms that the server makes available both before the SASL authentication exchange and after the negotiated SASL security layer (with at least data integrity protection) has been installed through the protocol's mechanism discovery facility. If the client finds that the integrity-protected list (the list obtained after the security layer was installed) contains a stronger mechanism than those in the previously obtained list, the client should assume that the previously obtained list was modified by an attacker and SHOULD close the underlying transport connection.
为了检测对支持的最低（或更低）安全机制的降级攻击，客户端可以发现服务器在SASL身份验证交换之前和协商的SASL安全层之后提供的SASL机制（至少具有数据完整性保护）已通过协议的机制发现设施安装。如果客户端发现完整性保护列表（安装安全层后获得的列表）包含比以前获得的列表中更强大的机制，则客户端应假定以前获得的列表已被攻击者修改，并应关闭基础传输连接。
The client's initiation of the SASL exchange, including the selection of a SASL mechanism, is done in the clear and may be modified by an
客户启动SASL交换，包括选择SASL机制，是在clear中完成的，可以由
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机制的设计应确保主动攻击者无法通过修改SASL机制名称和/或质询和响应来获得安全性较弱的身份验证。
Multi-level negotiation of security features is prone to downgrade attack. Protocol designers should avoid offering higher-level negotiation of security features in protocols (e.g., above SASL mechanism negotiation) and mechanism designers should avoid lower-level negotiation of security features in mechanisms (e.g., below SASL mechanism negotiation).
安全特性的多级协商容易受到降级攻击。协议设计者应避免在协议中提供更高级别的安全特性协商（例如，高于SASL机制协商），机制设计者应避免在机制中提供较低级别的安全特性协商（例如，低于SASL机制协商）。
Some mechanisms may be subject to replay attacks unless protected by external data security services (e.g., TLS).
某些机制可能受到重播攻击，除非受到外部数据安全服务（例如TLS）的保护。
Most existing SASL security layers do not themselves offer protection against truncation attack. In a truncation attack, the active attacker causes the protocol session to be closed, causing a truncation of the possibly integrity-protected data stream that leads to behavior of one or both the protocol peers that inappropriately benefits the attacker. Truncation attacks are fairly easy to defend against in connection-oriented application-level protocols. A protocol can defend against these attacks by ensuring that each information exchange has a clear final result and that each protocol session has a graceful closure mechanism, and that these are integrity protected.
大多数现有的SASL安全层本身并不提供针对截断攻击的保护。在截断攻击中，主动攻击者会关闭协议会话，从而截断可能受完整性保护的数据流，从而导致一个或两个协议对等方的行为不适当地使攻击者受益。在面向连接的应用程序级协议中，截断攻击很容易防御。协议可以通过确保每个信息交换都有一个明确的最终结果、每个协议会话都有一个优雅的关闭机制以及这些完整性受到保护来抵御这些攻击。
When use of a security layer is negotiated by the authentication protocol exchange, the receiver SHOULD handle gracefully any protected data buffer larger than the defined/negotiated maximal size. In particular, it MUST NOT blindly allocate the amount of memory specified in the buffer size field, as this might cause the "out of memory" condition. If the receiver detects a large block, it SHOULD close the connection.
当认证协议交换协商使用安全层时，接收方应妥善处理任何大于定义/协商的最大大小的受保护数据缓冲区。特别是，它不能盲目地分配缓冲区大小字段中指定的内存量，因为这可能导致“内存不足”情况。如果接收器检测到大数据块，则应关闭连接。
Many mechanisms are subject to various passive attacks, including simple eavesdropping of unprotected credential information as well as online and offline dictionary attacks of protected credential information.
许多机制都会受到各种被动攻击，包括对未受保护的凭证信息的简单窃听以及对受保护凭证信息的在线和离线字典攻击。
The secure or administratively permitted lifetimes of SASL mechanisms' security layers are finite. Cryptographic keys weaken as they are used and as time passes; the more time and/or cipher-text that a cryptanalyst has after the first use of the a key, the easier it is for the cryptanalyst to mount attacks on the key.
SASL机制的安全层的安全或管理上允许的生存期是有限的。加密密钥在使用时会随着时间的推移而减弱；密码分析员在首次使用密钥后拥有的时间和/或密文越多，密码分析员就越容易对密钥发起攻击。
Administrative limits on a security layer's lifetime may take the form of time limits expressed in X.509 certificates, in Kerberos V tickets, or in directories, and are often desired. In practice, one likely effect of administrative lifetime limits is that applications may find that security layers stop working in the middle of application protocol operation, such as, perhaps, during large data transfers. As the result of this, the connection will be closed (see Section 3.7), which will result in an unpleasant user experience.
安全层生命周期的管理限制可能采用X.509证书、Kerberos V票证或目录中表示的时间限制形式，通常是需要的。在实践中，管理寿命限制的一个可能的影响是，应用程序可能会发现安全层在应用协议操作的中间停止工作，例如，在大数据传输期间。因此，连接将被关闭（见第3.7节），这将导致不愉快的用户体验。
Re-keying (key renegotiation process) is a way of addressing the weakening of cryptographic keys. The SASL framework does not itself provide for re-keying; SASL mechanisms may. Designers of future SASL mechanisms should consider providing re-keying services.
重新设置密钥（密钥重新协商过程）是解决加密密钥弱化问题的一种方法。SASL框架本身不提供重设密钥；SASL机制可能会失效。未来SASL机制的设计者应该考虑提供重新键控服务。
Implementations that wish to re-key SASL security layers where the mechanism does not provide for re-keying SHOULD reauthenticate the same IDs and replace the expired or soon-to-expire security layers. This approach requires support for reauthentication in the application protocols (see Section 3.8).
在机制未提供密钥更新的情况下，希望对SASL安全层进行密钥更新的实现应重新验证相同的ID，并替换已过期或即将过期的安全层。这种方法需要在应用程序协议中支持重新验证（见第3.8节）。
Protocol designers and implementors should understand the security considerations of mechanisms so they may select mechanisms that are applicable to their needs.
协议设计者和实现者应该了解机制的安全考虑因素，以便他们可以选择适合自己需要的机制。
Distributed server implementations need to be careful in how they trust other parties. In particular, authentication secrets should only be disclosed to other parties that are trusted to manage and use those secrets in a manner acceptable to the disclosing party. Applications using SASL assume that SASL security layers providing data confidentiality are secure even when an attacker chooses the text to be protected by the security layer. Similarly, applications assume that the SASL security layer is secure even if the attacker can manipulate the cipher-text output of the security layer. New SASL mechanisms are expected to meet these assumptions.
分布式服务器实现需要注意如何信任其他方。特别是，认证机密应仅披露给受信任的其他方，以披露方可接受的方式管理和使用这些机密。使用SASL的应用程序假定提供数据机密性的SASL安全层是安全的，即使攻击者选择由安全层保护的文本。类似地，应用程序假定SASL安全层是安全的，即使攻击者可以操纵安全层的密文输出。预计新的SASL机制将满足这些假设。
Unicode security considerations [UTR36] apply to authorization identity strings, as well as UTF-8 [RFC3629] security considerations where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454] security considerations also apply where used.
Unicode安全注意事项[UTR36]适用于授权标识字符串，以及使用UTF-8时的UTF-8[RFC3629]安全注意事项。SASLprep[RFC4013]和StringPrep[RFC3454]安全注意事项在使用时也适用。
The SASL mechanism registry is maintained by IANA. The registry is currently available at <http://www.iana.org/assignments/sasl-mechanisms>.
SASL机制注册表由IANA维护。注册处现可于<http://www.iana.org/assignments/sasl-mechanisms>.
The purpose of this registry is not only to ensure uniqueness of values used to name SASL mechanisms, but also to provide a definitive reference to technical specifications detailing each SASL mechanism available for use on the Internet.
此注册表的目的不仅是确保用于命名SASL机制的值的唯一性，还提供详细说明互联网上可用的每个SASL机制的技术规范的明确参考。
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机制名称语法的名称都可以注册。
The procedure detailed in Section 7.1.1 is to be used for registration of a value naming a specific individual mechanism.
第7.1.1节中详述的程序将用于登记命名特定单独机制的值。
The procedure detailed in Section 7.1.2 is to be used for registration of a value naming a family of related mechanisms.
第7.1.2节中详述的程序将用于登记命名一系列相关机构的值。
Comments may be included in the registry as discussed in Section 7.1.3 and may be changed as discussed in Section 7.1.4.
注释可包括在第7.1.3节所述的注册表中，并可根据第7.1.4节所述进行更改。
The SASL mechanism registry has been updated to reflect that this document provides the definitive technical specification for SASL and that this section provides the registration procedures for this registry.
SASL机制注册已更新，以反映本文件提供了SASL的最终技术规范，本节提供了该注册的注册程序。
IANA will register new SASL mechanism names on a First Come First Served basis, as defined in BCP 26 [RFC2434]. IANA has the right to reject obviously bogus registration requests, but will perform no review of claims made in the registration form.
IANA将按照BCP 26[RFC2434]中的定义，以先到先得的方式注册新的SASL机制名称。IANA有权拒绝明显虚假的注册请求，但不会对注册表格中的申请进行审查。
Registration of a SASL mechanism is requested by filling in the following template:
通过填写以下模板请求注册SASL机制：
Subject: Registration of SASL mechanism X
主题：SASL机制X的注册
SASL mechanism name (or prefix for the family):
SASL机构名称（或族的前缀）：
Security considerations:
安全考虑：
Published specification (recommended):
已发布规范（推荐）：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
预期用途：（通用、有限用途或过时）
Owner/Change controller:
业主/变更控制人：
Note: (Any other information that the author deems relevant may be added here.)
注：（作者认为相关的任何其他信息可在此添加。）
and sending it via electronic mail to IANA at <iana@iana.org>.
并通过电子邮件发送给IANA<iana@iana.org>.
While this registration procedure does not require expert review, 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机制进行标准化。
As noted above, there is no general naming convention for SASL mechanisms. However, specifications may reserve a portion of the SASL mechanism namespace for a set of related SASL mechanisms, a "family" of SASL mechanisms. Each family of SASL mechanisms is identified by a unique prefix, such as X-. Registration of new SASL mechanism family names requires expert review as defined in BCP 26 [RFC2434].
如上所述，SASL机制没有通用的命名约定。然而，规范可能会为一组相关的SASL机制（SASL机制的“家族”）保留一部分SASL机制名称空间。SASL机制的每个家族都由一个唯一的前缀标识，例如X-。根据BCP 26[RFC2434]的定义，新SASL机制家族名称的注册需要专家审查。
Registration of a SASL family name is requested by filling in the following template:
通过填写以下模板，申请注册SASL姓氏：
Subject: Registration of SASL mechanism family X
主题：SASL机构系列X的注册
SASL family name (or prefix for the family):
SASL族名称（或族的前缀）：
Security considerations:
安全考虑：
Published specification (recommended):
已发布规范（推荐）：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
预期用途：（通用、有限用途或过时）
Owner/Change controller:
业主/变更控制人：
Note: (Any other information that the author deems relevant may be added here.)
注：（作者认为相关的任何其他信息可在此添加。）
and sending it via electronic mail to the IETF SASL mailing list at <ietf-sasl@imc.org> and carbon copying IANA at <iana@iana.org>. After allowing two weeks for community input on the IETF SASL mailing list, the expert will determine the appropriateness of the registration request and either approve or disapprove the request with notice to the requestor, the mailing list, and IANA.
并通过电子邮件发送至IETF SASL邮件列表，地址为<IETF-sasl@imc.org>以及<iana@iana.org>. 在允许社区在IETF SASL邮件列表上输入两周后，专家将确定注册请求的适当性，并在通知请求者、邮件列表和IANA的情况下批准或不批准该请求。
The review should focus on the appropriateness of the requested family name for the proposed use and the appropriateness of the proposed naming and registration plan for existing and future mechanism names in the family. The scope of this request review may entail consideration of relevant aspects of any provided technical specification, such as their IANA Considerations section. However, this review is narrowly focused on the appropriateness of the requested registration and not on the overall soundness of any provided technical specification.
审查应侧重于拟议用途所需姓氏的适当性，以及家族中现有和未来机制名称的拟议命名和登记计划的适当性。该请求审查的范围可能需要考虑任何提供的技术规范的相关方面，如IANA考虑部分。然而，本次审查狭隘地侧重于所请求注册的适当性，而不是所提供技术规范的总体可靠性。
Authors are encouraged to pursue community review by posting the technical specification as an Internet-Draft and soliciting comment by posting to appropriate IETF mailing lists.
鼓励作者通过将技术规范作为互联网草案发布，并通过发布到适当的IETF邮件列表征求意见，来进行社区审查。
Comments on a registered SASL mechanism/family should first be sent to the "owner" of the mechanism/family and/or to the <ietf-sasl@imc.org> mailing list.
关于已注册SASL机构/系列的评论应首先发送给机构/系列的“所有者”和/或<ietf-sasl@imc.org>邮件列表。
Submitters of comments may, after a reasonable attempt to contact the owner, request IANA to attach their comment to the SASL mechanism registration itself by sending mail to <iana@iana.org>. At IANA's sole discretion, IANA may attach the comment to the SASL mechanism's registration.
在合理尝试联系所有者后，意见提交人可以通过向以下地址发送邮件，请求IANA将其意见附加到SASL机制注册本身<iana@iana.org>. IANA可自行决定将意见附在SASL机制的注册上。
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, has 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 that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended usage" 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 that are on the IETF standards track.
IESG被认为是IETF标准轨道上所有SASL机制的所有者。
The IANA has updated the SASL mechanisms registry as follows:
IANA已将SASL机制注册表更新如下：
1) Changed the "Intended usage" of the KERBEROS_V4 and SKEY mechanism registrations to OBSOLETE.
1) 将KERBEROS_V4和SKEY机制注册的“预期用途”更改为已过时。
2) Changed the "Published specification" of the EXTERNAL mechanism to this document as indicated below:
2) 将外部机构的“发布规范”更改为本文件，如下所示：
Subject: Updated Registration of SASL mechanism EXTERNAL
Family of SASL mechanisms: NO
SASL mechanism name: EXTERNAL
Security considerations: See A.3 of RFC 4422
Published specification (optional, recommended): RFC 4422
Person & email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Intended usage: COMMON
Owner/Change controller: IESG <iesg@ietf.org>
Note: Updates existing entry for EXTERNAL
Subject: Updated Registration of SASL mechanism EXTERNAL
Family of SASL mechanisms: NO
SASL mechanism name: EXTERNAL
Security considerations: See A.3 of RFC 4422
Published specification (optional, recommended): RFC 4422
Person & email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Intended usage: COMMON
Owner/Change controller: IESG <iesg@ietf.org>
Note: Updates existing entry for EXTERNAL
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2244] Newman, C. and J. G. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[RFC2244]Newman，C.和J.G.Myers，“ACAP——应用程序配置访问协议”，RFC2244，1997年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化弦的准备（“stringprep”）”，RFC 3454，2002年12月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC40113，2005年2月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.
[ASCII]编码字符集——信息交换用7位美国标准代码，ANSI X3.4-1986。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[Unicode]Unicode联盟“Unicode标准，版本3.2.0”由“Unicode标准，版本3.0”（雷丁，马萨诸塞州，Addison-Wesley，2000.ISBN 0-201-61633-5）定义，并由“Unicode标准附录27:Unicode 3.1”修订(http://www.unicode.org/reports/tr27/)根据“Unicode标准附录28:Unicode 3.2”(http://www.unicode.org/reports/tr28/).
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report #17, Character Encoding Model", UTR17, <http://www.unicode.org/unicode/reports/tr17/>, August 2000.
[CharModel]Whistler，K.和M.Davis，“Unicode技术报告#17，字符编码模型”，UTR17<http://www.unicode.org/unicode/reports/tr17/>，2000年8月。
[Glossary] The Unicode Consortium, "Unicode Glossary", <http://www.unicode.org/glossary/>.
[词汇表]Unicode联盟，“Unicode词汇表”<http://www.unicode.org/glossary/>.
[RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC 3206, February 2002.
[RFC3206]Gellens，R.，“系统和认证POP响应代码”，RFC3206，2002年2月。
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[RFC3548]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC3548，2003年7月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[SASL-GSSAPI] Melnikov, A. (Editor), "The Kerberos V5 ("GSSAPI") SASL Mechanism", Work in Progress, May 2006.
[SASL-GSSAPI]Melnikov，A.（编辑），“Kerberos V5（“GSSAPI”）SASL机制”，正在进行的工作，2006年5月。
[UTR36] Davis, M., "(Draft) Unicode Technical Report #36, Character Encoding Model", UTR17, <http://www.unicode.org/unicode/reports/tr36/>, February 2005.
[UTR36]Davis，M.，“Unicode技术报告草案#36，字符编码模型”，UTR17<http://www.unicode.org/unicode/reports/tr36/>，2005年2月。
[CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in Progress.
[CRAM-MD5]Nerenberg，L.，“CRAM-MD5 SASL机制”，正在进行中。
[DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest Authentication as a SASL Mechanism", Work in Progress, March 2006.
[DIGEST-MD5]Leach，P.，C.Newman和A.Melnikov，“使用摘要认证作为SASL机制”，正在进行的工作，2006年3月。
This document is a revision of RFC 2222 written by John Myers.
本文件是John Myers编写的RFC 2222的修订版。
This revision is a product of the IETF Simple Authentication and Security Layer (SASL) Working Group.
本修订版是IETF简单认证和安全层（SASL）工作组的产品。
The following individuals contributed significantly to this revision: Abhijit Menon-Sen, Hallvard Furuseth, Jeffrey Hutzelman, John Myers, Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL 'Bob' Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim Alsop, and Tony Hansen.
以下个人对此次修订做出了重大贡献：阿比吉特·梅农·森、哈尔瓦德·福鲁斯、杰弗里·哈泽尔曼、约翰·迈尔斯、卢克·霍华德、马格努斯·尼斯特罗姆、尼古拉斯·威廉姆斯、彼得·圣安德烈、RL“鲍勃·摩根”、罗伯·西姆博斯基、萨姆·哈特曼、西蒙·约瑟夫森、蒂姆·阿尔索普和托尼·汉森。
This appendix is normative.
本附录为规范性附录。
The EXTERNAL mechanism allows a client to request the server to use credentials established by means external to the mechanism to authenticate the client. The external means may be, for instance, IP Security [RFC4301] or TLS [RFC4346] services. In absence of some a priori agreement between the client and the server, the client cannot make any assumption as to what external means the server has used to obtain the client's credentials, nor make an assumption as to the form of credentials. For example, the client cannot assume that the server will use the credentials the client has established via TLS.
外部机制允许客户端请求服务器使用通过该机制外部的方式建立的凭据对客户端进行身份验证。例如，外部手段可以是IP安全[RFC4301]或TLS[RFC4346]服务。在客户机和服务器之间没有某种先验协议的情况下，客户机无法对服务器用于获取客户机凭据的外部手段做出任何假设，也无法对凭据的形式做出任何假设。例如，客户端不能假设服务器将使用客户端通过TLS建立的凭据。
The name of this mechanism is "EXTERNAL".
此机制的名称为“外部”。
The mechanism does not provide a security layer.
该机制不提供安全层。
The mechanism is capable of transferring an authorization identity string. If empty, the client is requesting to act as the identity the server has associated with the client's credentials. If non-empty, the client is requesting to act as the identity represented by the string.
该机制能够传输授权标识字符串。如果为空，则客户端请求充当服务器与客户端凭据关联的标识。如果非空，则客户端请求充当字符串表示的标识。
The client is expected to send data first in the authentication exchange. Where the client does not provide an initial response data in its request to initiate the authentication exchange, the server is to respond to the request with an empty initial challenge and then the client is to provide its initial response.
客户端应首先在身份验证交换中发送数据。如果客户端在其启动身份验证交换的请求中未提供初始响应数据，则服务器将使用空的初始质询响应该请求，然后客户端将提供其初始响应。
The client sends the initial response containing the UTF-8 [RFC3629] encoding of the requested authorization identity string. This response is non-empty when the client is requesting to act as the identity represented by the (non-empty) string. This response is empty when the client is requesting to act as the identity the server associated with its authentication credentials.
客户端发送初始响应，其中包含请求的授权标识字符串的UTF-8[RFC3629]编码。当客户端请求充当（非空）字符串表示的标识时，此响应为非空。当客户端请求充当服务器与其身份验证凭据关联的身份时，此响应为空。
The syntax of the initial response is specified as a value of the <extern-initial-resp> production detailed below using the Augmented Backus-Naur Form (ABNF) [RFC4234] notation.
初始响应的语法被指定为下面使用扩充的Backus Naur Form（ABNF）[RFC4234]表示法详述的<extern initial resp>生成值。
external-initial-resp = authz-id-string
authz-id-string = *( UTF8-char-no-nul )
UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-no-nul = %x01-7F
external-initial-resp = authz-id-string
authz-id-string = *( UTF8-char-no-nul )
UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-no-nul = %x01-7F
where the <UTF8-2>, <UTF8-3>, and <UTF8-4> productions are as defined in [RFC3629].
其中，<UTF8-2>、<UTF8-3>和<UTF8-4>产品如[RFC3629]中所定义。
There are no additional challenges and responses.
没有其他挑战和应对措施。
Hence, the server is to return the outcome of the authentication exchange.
因此，服务器将返回身份验证交换的结果。
The exchange fails if
如果
- the client has not established its credentials via external means,
- 客户尚未通过外部手段建立其凭证，
- the client's credentials are inadequate,
- 客户的凭证不充分，
- the client provided an empty authorization identity string and the server is unwilling or unable to associate an authorization identity with the client's credentials,
- 客户端提供了空的授权标识字符串，而服务器不愿意或无法将授权标识与客户端的凭据关联，
- the client provided a non-empty authorization identity string that is invalid per the syntax requirements of the applicable application protocol specification,
- 客户端提供的非空授权标识字符串根据适用应用程序协议规范的语法要求无效，
- the client provided a non-empty authorization identity string representing an identity that the client is not allowed to act as, or
- 客户端提供了非空的授权标识字符串，表示不允许客户端充当的标识，或
- the server is unwilling or unable to provide service to the client for any other reason.
- 由于任何其他原因，服务器不愿意或无法向客户端提供服务。
Otherwise the exchange is successful. When indicating a successful outcome, additional data is not provided.
否则交换就成功了。当表明结果成功时，不提供其他数据。
This section provides examples of EXTERNAL authentication exchanges. The examples are intended to help the readers understand the above text. The examples are not definitive. The Application Configuration Access Protocol (ACAP) [RFC2244] is used in the examples.
本节提供了外部身份验证交换的示例。这些示例旨在帮助读者理解上述文本。这些例子并不确定。示例中使用了应用程序配置访问协议（ACAP）[RFC2244]。
The first example shows use of EXTERNAL with an empty authorization identity. In this example, the initial response is not sent in the client's request to initiate the authentication exchange.
第一个示例显示了在授权标识为空的情况下使用EXTERNAL。在本例中，初始响应不会在客户端启动身份验证交换的请求中发送。
S: * ACAP (SASL "DIGEST-MD5")
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "DIGEST-MD5")
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
C: a002 AUTHENTICATE "EXTERNAL"
S: + ""
C: + ""
S: a002 OK "Authenticated"
S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
C: a002 AUTHENTICATE "EXTERNAL"
S: + ""
C: + ""
S: a002 OK "Authenticated"
The second example shows use of EXTERNAL with an authorization identity of "fred@example.com". In this example, the initial response is sent with the client's request to initiate the authentication exchange. This saves a round-trip.
第二个示例显示使用授权标识为“”的外部fred@example.com". 在本例中，初始响应随客户端请求一起发送，以启动身份验证交换。这节省了往返的时间。
S: * ACAP (SASL "DIGEST-MD5")
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
C: a002 AUTHENTICATE "EXTERNAL" {16+}
C: fred@example.com
S: a002 NO "Cannot assume requested authorization identity"
S: * ACAP (SASL "DIGEST-MD5")
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
C: a002 AUTHENTICATE "EXTERNAL" {16+}
C: fred@example.com
S: a002 NO "Cannot assume requested authorization identity"
The EXTERNAL mechanism provides no security protection; it is vulnerable to spoofing by either client or server, active attack, and eavesdropping. It should only be used when adequate security services have been established.
外部机制不提供安全保护；它容易受到客户端或服务器的欺骗、主动攻击和窃听。只有在建立了足够的安全服务后才应使用。
This appendix is non-normative.
本附录为非规范性附录。
The material in RFC 2222 was significantly rewritten in the production of this document.
RFC 2222中的材料在本文件的制作过程中被显著重写。
RFC 2222, by not stating that the authorization identity string was a string of Unicode characters, let alone character data, implied that the authorization identity string was a string of octets.
RFC 2222没有说明授权标识字符串是Unicode字符字符串，更不用说字符数据了，这意味着授权标识字符串是八位字节字符串。
- The authorization identity string is now defined as a string of Unicode characters. The NUL (U+0000) character is prohibited. While protocol specifications are responsible for defining the authorization identity form, as well as the Unicode string syntax and related semantics, mechanism specifications are responsible for defining how the Unicode string is carried in the authentication exchange.
- 授权标识字符串现在定义为Unicode字符字符串。禁止使用NUL（U+0000）字符。协议规范负责定义授权标识形式以及Unicode字符串语法和相关语义，而机制规范负责定义如何在身份验证交换中携带Unicode字符串。
- Deleted "If so, when the client does not send data first, the initial challenge MUST be specified as being an empty challenge."
- 删除“如果是，当客户端不首先发送数据时，必须将初始质询指定为空质询。”
The following technical change was made to the EXTERNAL mechanism:
对外部机制进行了以下技术更改：
- The authorization identity string is to be UTF-8 encoded.
- 授权标识字符串将采用UTF-8编码。
Note that protocol and mechanism specification requirements have been significantly tightened. Existing protocol and mechanism specifications will need to be updated to meet these requirements.
请注意，协议和机制规范要求已明显收紧。现有的协议和机制规范需要更新以满足这些要求。
Editors' Addresses
编辑地址
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex, TW12 2BX, United Kingdom
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton，Middlesex，TW12 2BX，英国
EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/
EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/
Kurt D. Zeilenga OpenLDAP Foundation
库尔特D.Zeeliga OpenLDAP基金会
EMail: Kurt@OpenLDAP.org
EMail: Kurt@OpenLDAP.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。