Network Working Group K. Zeilenga, Ed.
Request for Comments: 4505 OpenLDAP Foundation
Obsoletes: 2245 June 2006
Category: Standards Track
Network Working Group K. Zeilenga, Ed.
Request for Comments: 4505 OpenLDAP Foundation
Obsoletes: 2245 June 2006
Category: Standards Track
Anonymous 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
摘要
On the Internet, it is common practice to permit anonymous access to various services. Traditionally, this has been done with a plain-text password mechanism using "anonymous" as the user name and using optional trace information, such as an email address, as the password. As plain-text login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework.
在互联网上，允许匿名访问各种服务是常见的做法。传统上，这是通过纯文本密码机制完成的，使用“匿名”作为用户名，使用可选的跟踪信息（如电子邮件地址）作为密码。由于新的IETF协议不允许使用纯文本登录命令，因此需要在简单身份验证和安全层（SASL）框架的上下文中提供匿名登录的新方法。
This document defines an anonymous mechanism for the Simple Authentication and Security Layer ([SASL]) framework. The name associated with this mechanism is "ANONYMOUS".
本文档为简单身份验证和安全层（[SASL]）框架定义了匿名机制。与此机制关联的名称为“匿名”。
Unlike many other SASL mechanisms, whose purpose is to authenticate and identify the user to a server, the purpose of this SASL mechanism is to allow the user to gain access to services or resources without requiring the user to establish or otherwise disclose their identity to the server. That is, this mechanism provides an anonymous login method.
与许多其他SASL机制（其目的是向服务器验证和标识用户）不同，此SASL机制的目的是允许用户访问服务或资源，而无需用户建立或以其他方式向服务器披露其身份。也就是说，该机制提供了匿名登录方法。
This mechanism does not provide a security layer.
此机制不提供安全层。
This document replaces RFC 2245. Changes since RFC 2245 are detailed in Appendix A.
本文件取代RFC 2245。附录A详细说明了RFC 2245以来的变化。
The mechanism consists of a single message from the client to the server. The client may include in this message trace information in the form of a string of [UTF-8]-encoded [Unicode] characters prepared in accordance with [StringPrep] and the "trace" stringprep profile defined in Section 3 of this document. The trace information, which has no semantical value, should take one of two forms: an Internet email address, or an opaque string that does not contain the '@' (U+0040) character and that can be interpreted by the system administrator of the client's domain. For privacy reasons, an Internet email address or other information identifying the user should only be used with permission from the user.
该机制由从客户端到服务器的单个消息组成。客户机可在该消息中包括按照[StringPrep]和本文件第3节中定义的“trace”StringPrep配置文件准备的[UTF-8]编码的[Unicode]字符字符串形式的跟踪信息。没有语义值的跟踪信息应采用两种形式之一：Internet电子邮件地址或不包含“@”（U+0040）字符且可由客户端域的系统管理员解释的不透明字符串。出于隐私原因，互联网电子邮件地址或其他识别用户的信息只能在获得用户许可的情况下使用。
A server that permits anonymous access will announce support for the ANONYMOUS mechanism and allow anyone to log in using that mechanism, usually with restricted access.
允许匿名访问的服务器将宣布对匿名机制的支持，并允许任何人使用该机制登录，通常访问受限。
A formal grammar for the client message using Augmented BNF [ABNF] is provided below as a tool for understanding this technical specification.
下面提供了使用增广BNF[ABNF]的客户机消息的正式语法，作为理解本技术规范的工具。
message = [ email / token ]
;; to be prepared in accordance with Section 3
message = [ email / token ]
;; to be prepared in accordance with Section 3
UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040)
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 = %x00-3F / %x41-7F ;; less '@' (U+0040)
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
TCHAR = UTF1 / UTF2 / UTF3 / UTF4
;; any UTF-8 encoded Unicode character
;; except '@' (U+0040)
TCHAR = UTF1 / UTF2 / UTF3 / UTF4
;; any UTF-8 encoded Unicode character
;; except '@' (U+0040)
email = addr-spec ;; as defined in [IMAIL]
电子邮件=地址规范；；如[IMAIL]中所定义
token = 1*255TCHAR
token = 1*255TCHAR
Note to implementors: The <token> production is restricted to 255 UTF-8-encoded Unicode characters. As the encoding of a characters uses a sequence of 1 to 4 octets, a token may be as long as 1020 octets.
实现者注意：<token>产品限制为255个UTF-8编码的Unicode字符。由于字符的编码使用1到4个八位字节的序列，因此令牌的长度可能长达1020个八位字节。
This section defines the "trace" profile of [StringPrep]. This profile is designed for use with the SASL ANONYMOUS Mechanism. Specifically, the client is to prepare the <message> production in accordance with this profile.
本节定义了[StringPrep]的“跟踪”配置文件。此配置文件设计用于SASL匿名机制。具体而言，客户应根据此配置文件准备<message>产品。
The character repertoire of this profile is Unicode 3.2 [Unicode].
此配置文件的字符集为Unicode 3.2[Unicode]。
No mapping is required by this profile.
此配置文件不需要任何映射。
No Unicode normalization is required by this profile.
此配置文件不需要Unicode规范化。
The list of unassigned code points for this profile is that provided in Appendix A of [StringPrep]. Unassigned code points are not prohibited.
此配置文件的未分配代码点列表见[StringPrep]的附录A。不禁止未指定的代码点。
Characters from the following tables of [StringPrep] are prohibited:
禁止使用[StringPrep]下表中的字符：
- C.2.1 (ASCII control characters) - C.2.2 (Non-ASCII control characters) - C.3 (Private use characters) - C.4 (Non-character code points) - C.5 (Surrogate codes) - C.6 (Inappropriate for plain text) - C.8 (Change display properties are deprecated) - C.9 (Tagging characters)
- C.2.1（ASCII控制字符）-C.2.2（非ASCII控制字符）-C.3（专用字符）-C.4（非字符代码点）-C.5（代理代码）-C.6（不适用于纯文本）-C.8（不推荐更改显示属性）-C.9（标记字符）
No additional characters are prohibited.
不禁止使用其他字符。
This profile requires bidirectional character checking per Section 6 of [StringPrep].
此配置文件需要按照[StringPrep]第6节进行双向字符检查。
Here is a sample ANONYMOUS login between an IMAP client and server. In this example, "C:" and "S:" indicate lines sent by the client and server, respectively. If such lines are wrapped without a new "C:" or "S:" label, then the wrapping is for editorial clarity and is not part of the command.
下面是IMAP客户端和服务器之间的匿名登录示例。在本例中，“C:”和“S:”分别表示客户端和服务器发送的行。如果这些行没有新的“C:”或“S:”标签而被换行，则换行是为了编辑清晰，而不是命令的一部分。
Note that this example uses the IMAP profile [IMAP4] of SASL. The base64 encoding of challenges and responses as well as the "+ " preceding the responses are part of the IMAP4 profile, not part of SASL itself. Additionally, protocols with SASL profiles permitting an initial client response will be able to avoid the extra round trip below (the server response with an empty "+ ").
请注意，此示例使用SASL的IMAP配置文件[IMAP4]。挑战和响应的base64编码以及响应前的“+”是IMAP4配置文件的一部分，而不是SASL本身的一部分。此外，具有SASL配置文件的协议允许初始客户端响应，将能够避免下面的额外往返（服务器响应带有空“+”）。
In this example, the trace information is "sirhc".
在本例中，跟踪信息为“sirhc”。
S: * OK IMAP4 server ready
C: A001 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=ANONYMOUS
S: A001 OK done
C: A002 AUTHENTICATE ANONYMOUS
S: +
C: c2lyaGM=
S: A003 OK Welcome, trace information has been logged.
S: * OK IMAP4 server ready
C: A001 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=ANONYMOUS
S: A001 OK done
C: A002 AUTHENTICATE ANONYMOUS
S: +
C: c2lyaGM=
S: A003 OK Welcome, trace information has been logged.
The ANONYMOUS mechanism grants access to services and/or resources by anyone. For this reason, it should be disabled by default so that the administrator can make an explicit decision to enable it.
匿名机制允许任何人访问服务和/或资源。因此，默认情况下应该禁用它，以便管理员可以明确决定启用它。
If the anonymous user has any write privileges, a denial-of-service attack is possible by filling up all available space. This can be prevented by disabling all write access by anonymous users.
如果匿名用户具有任何写入权限，则可以通过填充所有可用空间来进行拒绝服务攻击。这可以通过禁用匿名用户的所有写访问来防止。
If anonymous users have read and write access to the same area, the server can be used as a communication mechanism to exchange information anonymously. Servers that accept anonymous submissions should implement the common "drop box" model, which forbids anonymous read access to the area where anonymous submissions are accepted.
如果匿名用户具有对同一区域的读写访问权限，则可以将服务器用作匿名交换信息的通信机制。接受匿名提交的服务器应实现公共“drop box”模型，该模型禁止匿名读取接受匿名提交的区域。
If the anonymous user can run many expensive operations (e.g., an IMAP SEARCH BODY command), this could enable a denial-of-service attack. Servers are encouraged to reduce the priority of anonymous users or limit their resource usage.
如果匿名用户可以运行许多昂贵的操作（例如，IMAP SEARCH BODY命令），这可能会导致拒绝服务攻击。鼓励服务器降低匿名用户的优先级或限制其资源使用。
While servers may impose a limit on the number of anonymous users, note that such limits enable denial-of-service attacks and should be used with caution.
虽然服务器可能会对匿名用户的数量施加限制，但请注意，此类限制会导致拒绝服务攻击，应谨慎使用。
The trace information is not authenticated, so it can be falsified. This can be used as an attempt to get someone else in trouble for access to questionable information. Administrators investigating abuse need to realize that this trace information may be falsified.
跟踪信息未经过身份验证，因此可能被伪造。这可能被用作试图让其他人在访问可疑信息时遇到麻烦。调查滥用行为的管理员需要意识到这些跟踪信息可能是伪造的。
A client that uses the user's correct email address as trace information without explicit permission may violate that user's privacy. Anyone who accesses an anonymous archive on a sensitive subject (e.g., sexual abuse) likely has strong privacy needs. Clients should not send the email address without the explicit permission of the user and should offer the option of supplying no trace information, thus only exposing the source IP address and time.
未经明确许可而将用户的正确电子邮件地址用作跟踪信息的客户端可能会侵犯该用户的隐私。任何访问敏感主题（如性虐待）匿名档案的人都可能有强烈的隐私需求。未经用户明确许可，客户端不应发送电子邮件地址，并应提供不提供跟踪信息的选项，从而仅公开源IP地址和时间。
Anonymous proxy servers could enhance this privacy but would have to consider the resulting potential denial-of-service attacks.
匿名代理服务器可以增强这种隐私，但必须考虑由此产生的潜在拒绝服务攻击。
Anonymous connections are susceptible to man-in-the-middle attacks that view or alter the data transferred. Clients and servers are encouraged to support external data security services.
匿名连接容易受到中间人攻击，即查看或更改传输的数据。鼓励客户机和服务器支持外部数据安全服务。
Protocols that fail to require an explicit anonymous login are more susceptible to break-ins given certain common implementation techniques. Specifically, Unix servers that offer user login may initially start up as root and switch to the appropriate user id after an explicit login command. Normally, such servers refuse all data access commands prior to explicit login and may enter a restricted security environment (e.g., the Unix chroot(2) function) for anonymous users. If anonymous access is not explicitly requested, the entire data access machinery is exposed to external security attacks without the chance for explicit protective measures. Protocols that offer restricted data access should not allow anonymous data access without an explicit login step.
鉴于某些常见的实现技术，不需要显式匿名登录的协议更容易被入侵。具体来说，提供用户登录的Unix服务器最初可能以root用户身份启动，并在显式登录命令后切换到相应的用户id。通常情况下，此类服务器在显式登录之前拒绝所有数据访问命令，并可能为匿名用户进入受限制的安全环境（例如Unix chroot（2）函数）。如果未明确请求匿名访问，则整个数据访问机制将受到外部安全攻击，而没有明确的保护措施。提供受限数据访问的协议不应允许在没有显式登录步骤的情况下进行匿名数据访问。
General [SASL] security considerations apply to this mechanism.
一般[SASL]安全注意事项适用于此机制。
[StringPrep] security considerations and [Unicode] security considerations discussed in [StringPrep] apply to this mechanism. [UTF-8] security considerations also apply.
[StringPrep]中讨论的[StringPrep]安全注意事项和[Unicode]安全注意事项适用于此机制。[UTF-8]安全注意事项也适用。
The SASL Mechanism registry [IANA-SASL] entry for the ANONYMOUS 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 ANONYMOUS
致：iana@iana.org主题：更新SASL机制匿名注册
SASL mechanism name: ANONYMOUS
Security considerations: See RFC 4505.
Published specification (optional, recommended): RFC 4505
Person & email address to contact for further information:
Kurt Zeilenga <Kurt@OpenLDAP.org>
Chris Newman <Chris.Newman@sun.com>
Intended usage: COMMON
Author/Change controller: IESG <iesg@ietf.org>
Note: Updates existing entry for ANONYMOUS
SASL mechanism name: ANONYMOUS
Security considerations: See RFC 4505.
Published specification (optional, recommended): RFC 4505
Person & email address to contact for further information:
Kurt Zeilenga <Kurt@OpenLDAP.org>
Chris Newman <Chris.Newman@sun.com>
Intended usage: COMMON
Author/Change controller: IESG <iesg@ietf.org>
Note: Updates existing entry for ANONYMOUS
The [StringPrep] profile "trace", first defined in this RFC, has been registered:
本RFC中首次定义的[StringPrep]配置文件“跟踪”已注册：
To: iana@iana.org Subject: Initial Registration of Stringprep "trace" profile
致：iana@iana.org主题：Stringprep“跟踪”配置文件的初始注册
Stringprep profile: trace
Published specification: RFC 4505
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Stringprep profile: trace
Published specification: RFC 4505
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
This document is a revision of RFC 2245 by Chris Newman. Portions of the grammar defined in Section 1 were borrowed from RFC 3629 by Francois Yergeau.
本文件是Chris Newman对RFC 2245的修订版。第1节中定义的语法部分由Francois Yergeau从RFC 3629中借用。
This document is a product of the IETF SASL WG.
本文件是IETF SASL工作组的产品。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[IMAIL]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[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月。
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ('stringprep')", RFC 3454, December 2002.
[StringPrep]Hoffman，P.和M.Blanchet，“国际化字符串（“StringPrep”）的准备”，RFC 34542002年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", RFC 3629 (also STD 63), November 2003.
[UTF-8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，RFC 3629（也叫STD 63），2003年11月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[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>.
This appendix is non-normative.
本附录为非规范性附录。
RFC 2245 allows the client to include optional trace information in the form of a human readable string. RFC 2245 restricted this string to US-ASCII. As the Internet is international, this document uses a string restricted to UTF-8 encoded Unicode characters. A "stringprep" profile is defined to precisely define which Unicode characters are allowed in this string. While the string remains restricted to 255 characters, the encoded length of each character may now range from 1 to 4 octets.
RFC 2245允许客户端以人类可读字符串的形式包含可选跟踪信息。RFC 2245将此字符串限制为US-ASCII。由于互联网是国际性的，本文档使用的字符串仅限于UTF-8编码的Unicode字符。定义“stringprep”配置文件以精确定义此字符串中允许使用哪些Unicode字符。虽然字符串限制为255个字符，但每个字符的编码长度现在可能在1到4个八位字节之间。
Additionally, a number of editorial changes were made.
此外，还进行了一些编辑性修改。
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）提供。