Network Working Group K. Zeilenga, Ed.
Request for Comments: 4616 OpenLDAP Foundation
Updates: 2595 August 2006
Category: Standards Track
Network Working Group K. Zeilenga, Ed.
Request for Comments: 4616 OpenLDAP Foundation
Updates: 2595 August 2006
Category: Standards Track
The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
简单认证和安全层（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
摘要
This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command.
本文档定义了一个简单的明文用户/密码简单身份验证和安全层（SASL）机制，称为普通机制。普通机制旨在与较低层提供的数据保密服务结合使用，用于缺少简单密码验证命令的协议中。
Clear-text, multiple-use passwords are simple, interoperate with almost all existing operating system authentication databases, and are useful for a smooth transition to a more secure password-based authentication mechanism. The drawback is that they are unacceptable for use over network connections where data confidentiality is not ensured.
明文、多用途密码非常简单，可以与几乎所有现有的操作系统身份验证数据库进行互操作，并且有助于顺利过渡到更安全的基于密码的身份验证机制。缺点是，在无法确保数据机密性的网络连接上使用它们是不可接受的。
This document defines the PLAIN Simple Authentication and Security Layer ([SASL]) mechanism for use in protocols with no clear-text login command (e.g., [ACAP] or [SMTP-AUTH]). This document updates RFC 2595, replacing Section 6. Changes since RFC 2595 are detailed in Appendix A.
本文档定义了用于无明文登录命令（例如[ACAP]或[SMTP-AUTH]）的协议的简单认证和安全层（[SASL]）机制。本文件更新了RFC 2595，取代了第6节。自RFC 2595以来的变化详见附录A。
The name associated with this mechanism is "PLAIN".
与此机制关联的名称为“普通”。
The PLAIN SASL mechanism does not provide a security layer.
普通SASL机制不提供安全层。
The PLAIN mechanism should not be used without adequate data security protection as this mechanism affords no integrity or confidentiality protections itself. The mechanism is intended to be used with data security protections provided by application-layer protocol, generally through its use of Transport Layer Security ([TLS]) services.
如果没有足够的数据安全保护，则不应使用普通机制，因为该机制本身不提供完整性或机密性保护。该机制旨在通过使用传输层安全（[TLS]）服务，与应用层协议提供的数据安全保护一起使用。
By default, implementations SHOULD advertise and make use of the PLAIN mechanism only when adequate data security services are in place. Specifications for IETF protocols that indicate that this mechanism is an applicable authentication mechanism MUST mandate that implementations support an strong data security service, such as TLS.
默认情况下，只有在有足够的数据安全服务时，实现才应该公布并使用普通机制。IETF协议的规范表明该机制是一种适用的身份验证机制，必须要求实现支持强大的数据安全服务，如TLS。
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 [Keywords].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
The mechanism consists of a single message, a string of [UTF-8] encoded [Unicode] characters, from the client to the server. The client presents the authorization identity (identity to act as), followed by a NUL (U+0000) character, followed by the authentication identity (identity whose password will be used), followed by a NUL (U+0000) character, followed by the clear-text password. As with other SASL mechanisms, the client does not provide an authorization identity when it wishes the server to derive an identity from the credentials and use that as the authorization identity.
该机制由一条消息组成，即从客户端到服务器的[UTF-8]编码的[Unicode]字符字符串。客户端显示授权标识（要充当的标识），后跟NUL（U+0000）字符，后跟身份验证标识（将使用其密码的标识），后跟NUL（U+0000）字符，后跟明文密码。与其他SASL机制一样，当客户机希望服务器从凭据派生身份并将其用作授权身份时，它不提供授权身份。
The formal grammar for the client message using Augmented BNF [ABNF] follows.
使用增广BNF[ABNF]的客户机消息的形式语法如下所示。
message = [authzid] UTF8NUL authcid UTF8NUL passwd
authcid = 1*SAFE ; MUST accept up to 255 octets
authzid = 1*SAFE ; MUST accept up to 255 octets
passwd = 1*SAFE ; MUST accept up to 255 octets
UTF8NUL = %x00 ; UTF-8 encoded NUL character
message = [authzid] UTF8NUL authcid UTF8NUL passwd
authcid = 1*SAFE ; MUST accept up to 255 octets
authzid = 1*SAFE ; MUST accept up to 255 octets
passwd = 1*SAFE ; MUST accept up to 255 octets
UTF8NUL = %x00 ; UTF-8 encoded NUL character
SAFE = UTF1 / UTF2 / UTF3 / UTF4
;; any UTF-8 encoded Unicode character except NUL
SAFE = UTF1 / UTF2 / UTF3 / UTF4
;; any UTF-8 encoded Unicode character except NUL
UTF1 = %x01-7F ;; except NUL
UTF2 = %xC2-DF UTF0
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
%xF4 %x80-8F 2(UTF0)
UTF0 = %x80-BF
UTF1 = %x01-7F ;; except NUL
UTF2 = %xC2-DF UTF0
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
%xF4 %x80-8F 2(UTF0)
UTF0 = %x80-BF
The authorization identity (authzid), authentication identity (authcid), password (passwd), and NUL character deliminators SHALL be transferred as [UTF-8] encoded strings of [Unicode] characters. As the NUL (U+0000) character is used as a deliminator, the NUL (U+0000) character MUST NOT appear in authzid, authcid, or passwd productions.
授权标识（authzid）、认证标识（authcid）、密码（passwd）和NUL字符删除器应作为[Unicode]字符的[UTF-8]编码字符串传输。由于NUL（U+0000）字符用作清除器，因此在authzid、authcid或passwd产品中不能出现NUL（U+0000）字符。
The form of the authzid production is specific to the application-level protocol's SASL profile [SASL]. The authcid and passwd productions are form-free. Use of non-visible characters or characters that a user may be unable to enter on some keyboards is discouraged.
authzid产品的形式特定于应用程序级协议的SASL概要文件[SASL]。authcid和passwd产品是无格式的。不鼓励使用不可见字符或用户无法在某些键盘上输入的字符。
Servers MUST be capable of accepting authzid, authcid, and passwd productions up to and including 255 octets. It is noted that the UTF-8 encoding of a Unicode character may be as long as 4 octets.
服务器必须能够接受多达255个八位字节（含255个八位字节）的authzid、authcid和passwd产品。注意，Unicode字符的UTF-8编码可能长达4个八位字节。
Upon receipt of the message, the server will verify the presented (in the message) authentication identity (authcid) and password (passwd) with the system authentication database, and it will verify that the authentication credentials permit the client to act as the (presented or derived) authorization identity (authzid). If both steps succeed, the user is authenticated.
收到消息后，服务器将使用系统身份验证数据库验证（消息中）提供的身份验证标识（authcid）和密码（passwd），并验证身份验证凭据是否允许客户端充当（提供的或派生的）授权标识（authzid）。如果两个步骤都成功，则对用户进行身份验证。
The presented authentication identity and password strings, as well as the database authentication identity and password strings, are to be prepared before being used in the verification process. The [SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED preparation algorithm. The SASLprep preparation algorithm is
提交的身份验证标识和密码字符串，以及数据库身份验证标识和密码字符串，在用于验证过程之前要准备好。[StringPrep]算法的[SASLPrep]配置文件是推荐的准备算法。SASLprep准备算法是
recommended to improve the likelihood that comparisons behave in an expected manner. The SASLprep preparation algorithm is not mandatory so as to allow the server to employ other preparation algorithms (including none) when appropriate. For instance, use of a different preparation algorithm may be necessary for the server to interoperate with an external system.
建议提高以预期方式进行比较的可能性。SASLprep准备算法不是强制性的，以便允许服务器在适当时使用其他准备算法（包括无）。例如，为了使服务器与外部系统互操作，可能需要使用不同的准备算法。
When preparing the presented strings using [SASLPrep], the presented strings are to be treated as "query" strings (Section 7 of [StringPrep]) and hence unassigned code points are allowed to appear in their prepared output. When preparing the database strings using [SASLPrep], the database strings are to be treated as "stored" strings (Section 7 of [StringPrep]) and hence unassigned code points are prohibited from appearing in their prepared output.
当使用[SASLPrep]准备呈现的字符串时，呈现的字符串将被视为“查询”字符串（参见[StringPrep]第7节），因此未分配的代码点允许出现在其准备的输出中。当使用[SASLPrep]准备数据库字符串时，数据库字符串将被视为“存储”字符串（《StringPrep》）第7节），因此未分配的代码点禁止出现在其准备的输出中。
Regardless of the preparation algorithm used, if the output of a non-invertible function (e.g., hash) of the expected string is stored, the string MUST be prepared before input to that function.
无论使用何种准备算法，如果存储了预期字符串的不可逆函数（如哈希）的输出，则必须在输入该函数之前准备该字符串。
Regardless of the preparation algorithm used, if preparation fails or results in an empty string, verification SHALL fail.
无论使用何种准备算法，如果准备失败或导致空字符串，验证应失败。
When no authorization identity is provided, the server derives an authorization identity from the prepared representation of the provided authentication identity string. This ensures that the derivation of different representations of the authentication identity produces the same authorization identity.
如果未提供授权标识，服务器将从提供的身份验证标识字符串的准备好的表示形式中派生授权标识。这确保了身份验证标识的不同表示形式的派生产生相同的授权标识。
The server MAY use the credentials to initialize any new authentication database, such as one suitable for [CRAM-MD5] or [DIGEST-MD5].
服务器可以使用凭据初始化任何新的身份验证数据库，例如适合[CRAM-MD5]或[DIGEST-MD5]的数据库。
This section provides pseudo-code illustrating the verification process (using hashed passwords and the SASLprep preparation function) discussed above. This section is not definitive.
本节提供了说明上述验证过程的伪代码（使用哈希密码和SASLprep准备函数）。本节不是决定性的。
boolean Verify(string authzid, string authcid, string passwd) {
string pAuthcid = SASLprep(authcid, true); # prepare authcid
string pPasswd = SASLprep(passwd, true); # prepare passwd
if (pAuthcid == NULL || pPasswd == NULL) {
return false; # preparation failed
}
if (pAuthcid == "" || pPasswd == "") {
return false; # empty prepared string
}
boolean Verify(string authzid, string authcid, string passwd) {
string pAuthcid = SASLprep(authcid, true); # prepare authcid
string pPasswd = SASLprep(passwd, true); # prepare passwd
if (pAuthcid == NULL || pPasswd == NULL) {
return false; # preparation failed
}
if (pAuthcid == "" || pPasswd == "") {
return false; # empty prepared string
}
storedHash = FetchPasswordHash(pAuthcid);
if (storedHash == NULL || storedHash == "") {
return false; # error or unknown authcid
}
storedHash = FetchPasswordHash(pAuthcid);
if (storedHash == NULL || storedHash == "") {
return false; # error or unknown authcid
}
if (!Compare(storedHash, Hash(pPasswd))) {
return false; # incorrect password
}
if (!Compare(storedHash, Hash(pPasswd))) {
return false; # incorrect password
}
if (authzid == NULL ) {
authzid = DeriveAuthzid(pAuthcid);
if (authzid == NULL || authzid == "") {
return false; # could not derive authzid
}
}
if (authzid == NULL ) {
authzid = DeriveAuthzid(pAuthcid);
if (authzid == NULL || authzid == "") {
return false; # could not derive authzid
}
}
if (!Authorize(pAuthcid, authzid)) {
return false; # not authorized
}
if (!Authorize(pAuthcid, authzid)) {
return false; # not authorized
}
return true;
}
return true;
}
The second parameter of the SASLprep function, when true, indicates that unassigned code points are allowed in the input. When the SASLprep function is called to prepare the password prior to computing the stored hash, the second parameter would be false.
SASLprep函数的第二个参数为true时，表示输入中允许未分配的代码点。当调用SASLprep函数以在计算存储的哈希之前准备密码时，第二个参数将为false。
The second parameter provided to the Authorize function is not prepared by this code. The application-level SASL profile should be consulted to determine what, if any, preparation is necessary.
提供给Authorize函数的第二个参数不是由此代码准备的。应咨询应用程序级SASL配置文件，以确定需要做哪些准备（如果有）。
Note that the DeriveAuthzid and Authorize functions (whether implemented as one function or two, whether designed in a manner in which these functions or whether the mechanism implementation can be reused elsewhere) require knowledge and understanding of mechanism and the application-level protocol specification and/or implementation details to implement.
请注意，DeriveAuthzid和Authorize函数（无论是作为一个函数实现还是作为两个函数实现，无论是以这些函数的方式设计的，还是机制实现是否可以在其他地方重用）需要了解和理解机制和应用程序级协议规范和/或实施细节。
Note that the Authorize function outcome is clearly dependent on details of the local authorization model and policy. Both functions may be dependent on other factors as well.
请注意，授权功能的结果显然取决于本地授权模型和策略的详细信息。这两种功能也可能取决于其他因素。
This section provides examples of PLAIN authentication exchanges. The examples are intended to help the readers understand the above text. The examples are not definitive.
本节提供了普通身份验证交换的示例。这些示例旨在帮助读者理解上述文本。这些例子并不确定。
"C:" and "S:" indicate lines sent by the client and server, respectively. "<NUL>" represents a single NUL (U+0000) character. The Application Configuration Access Protocol ([ACAP]) is used in the examples.
“C:”和“S:”分别表示客户端和服务器发送的行。“<NUL>”表示单个NUL（U+0000）字符。示例中使用了应用程序配置访问协议（[ACAP]）。
The first example shows how the PLAIN mechanism might be used for user authentication.
第一个示例显示了普通机制如何用于用户身份验证。
S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN")
C: a002 AUTHENTICATE "PLAIN"
S: + ""
C: {21}
C: <NUL>tim<NUL>tanstaaftanstaaf
S: a002 OK "Authenticated"
S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN")
C: a002 AUTHENTICATE "PLAIN"
S: + ""
C: {21}
C: <NUL>tim<NUL>tanstaaftanstaaf
S: a002 OK "Authenticated"
The second example shows how the PLAIN mechanism might be used to attempt to assume the identity of another user. In this example, the server rejects the request. Also, this example makes use of the protocol optional initial response capability to eliminate a round-trip.
第二个示例显示了如何使用普通机制来尝试假定另一个用户的身份。在本例中，服务器拒绝该请求。此外，该示例还利用协议可选的初始响应能力来消除往返。
S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN")
C: a002 AUTHENTICATE "PLAIN" {20+}
C: Ursel<NUL>Kurt<NUL>xipj3plmq
S: a002 NO "Not authorized to requested authorization identity"
S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN")
C: a002 AUTHENTICATE "PLAIN" {20+}
C: Ursel<NUL>Kurt<NUL>xipj3plmq
S: a002 NO "Not authorized to requested authorization identity"
As the PLAIN mechanism itself provided no integrity or confidentiality protections, it should not be used without adequate external data security protection, such as TLS services provided by many application-layer protocols. By default, implementations SHOULD NOT advertise and SHOULD NOT make use of the PLAIN mechanism unless adequate data security services are in place.
由于普通机制本身不提供完整性或机密性保护，因此在没有足够的外部数据安全保护（如许多应用层协议提供的TLS服务）的情况下，不应使用它。默认情况下，除非有足够的数据安全服务，否则实现不应该公布，也不应该使用普通机制。
When the PLAIN mechanism is used, the server gains the ability to impersonate the user to all services with the same password regardless of any encryption provided by TLS or other confidentiality protection mechanisms. Whereas many other authentication mechanisms have similar weaknesses, stronger SASL mechanisms address this issue. Clients are encouraged to have an operational mode where all mechanisms that are likely to reveal the user's password to the server are disabled.
当使用普通机制时，服务器可以使用相同的密码模拟用户访问所有服务，而不考虑TLS或其他保密保护机制提供的任何加密。尽管许多其他身份验证机制也有类似的弱点，但更强的SASL机制可以解决这个问题。鼓励客户机采用一种操作模式，在这种模式下，所有可能向服务器泄露用户密码的机制都被禁用。
General [SASL] security considerations apply to this mechanism.
一般[SASL]安全注意事项适用于此机制。
Unicode, [UTF-8], and [StringPrep] security considerations also apply.
Unicode、[UTF-8]和[StringPrep]安全注意事项也适用。
The SASL Mechanism registry [IANA-SASL] entry for the PLAIN mechanism has been updated by the IANA to reflect that this document now provides its technical specification.
IANA已经更新了普通机制的SASL机制注册表[IANA-SASL]条目，以反映本文件现在提供了其技术规范。
To: iana@iana.org Subject: Updated Registration of SASL mechanism PLAIN
致：iana@iana.org主题：SASL机制的更新注册
SASL mechanism name: PLAIN
Security considerations: See RFC 4616.
Published specification (optional, recommended): RFC 4616
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
IETF SASL WG <ietf-sasl@imc.org>
Intended usage: COMMON
Author/Change controller: IESG <iesg@ietf.org>
Note: Updates existing entry for PLAIN
SASL mechanism name: PLAIN
Security considerations: See RFC 4616.
Published specification (optional, recommended): RFC 4616
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
IETF SASL WG <ietf-sasl@imc.org>
Intended usage: COMMON
Author/Change controller: IESG <iesg@ietf.org>
Note: Updates existing entry for PLAIN
This document is a revision of RFC 2595 by Chris Newman. Portions of the grammar defined in Section 2 were borrowed from [UTF-8] by Francois Yergeau.
本文件是Chris Newman对RFC 2595的修订版。第2节中定义的语法部分由Francois Yergeau从[UTF-8]借用。
This document is a product of the IETF Simple Authentication and Security Layer (SASL) Working Group.
本文件是IETF简单认证和安全层（SASL）工作组的产品。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[Keywords] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SASL] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL]Melnikov，A.，Ed.，和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[SASLPrep] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[SASLPrep]Zeilenga，K.，“SASLPrep:Stringprep用户名和密码配置文件”，RFC 4013，2005年2月。
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[StringPrep]Hoffman，P.和M.Blanchet，“国际化弦的准备（“StringPrep”）”，RFC 3454，2002年12月。
[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/).
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[CRAM-MD5] Nerenberg, L., Ed., "The CRAM-MD5 SASL Mechanism", Work in Progress, June 2006.
[CRAM-MD5]Nerenberg，L.，编辑，“CRAM-MD5 SASL机制”，进展中的工作，2006年6月。
[DIGEST-MD5] Melnikov, A., Ed., "Using Digest Authentication as a SASL Mechanism", Work in Progress, June 2006.
[DIGEST-MD5]Melnikov，A.，Ed.，“使用摘要认证作为SASL机制”，正在进行的工作，2006年6月。
[IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS", <http://www.iana.org/assignments/sasl-mechanisms>.
[IANA-SASL]IANA，“简单身份验证和安全层（SASL）机制”<http://www.iana.org/assignments/sasl-mechanisms>.
[SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTP-AUTH]迈尔斯，J.，“用于身份验证的SMTP服务扩展”，RFC2554，1999年3月。
This appendix is non-normative.
本附录为非规范性附录。
This document replaces Section 6 of RFC 2595.
本文件取代RFC 2595第6节。
The specification details how the server is to compare client-provided character strings with stored character strings.
该规范详细说明了服务器如何将客户端提供的字符串与存储的字符串进行比较。
The ABNF grammar was updated. In particular, the grammar now allows LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the authzid, authcid, passwd productions. However, whether these control characters may be used depends on the string preparation rules applicable to the production. For passwd and authcid productions, control characters are prohibited. For authzid, one must consult the application-level SASL profile. This change allows PLAIN to carry all possible authorization identity strings allowed in SASL.
ABNF语法已更新。特别是，语法现在允许在authzid、authcid、passwd产品中使用换行（U+000A）和回车（U+000D）字符。但是，是否可以使用这些控制字符取决于适用于生产的字符串准备规则。对于passwd和authcid产品，禁止使用控制字符。对于authzid，必须参考应用程序级SASL概要文件。此更改允许PLAIN携带SASL中允许的所有可能的授权标识字符串。
Pseudo-code was added.
添加了伪代码。
The example section was expanded to illustrate more features of the PLAIN mechanism.
示例部分已扩展，以说明普通机构的更多功能。
Editor's Address
编辑地址
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）提供。