Network Working Group                                          C. Newman
Request for Comments: 2245                                      Innosoft
Category: Standards Track                                  November 1997
        
Network Working Group                                          C. Newman
Request for Comments: 2245                                      Innosoft
Category: Standards Track                                  November 1997
        

Anonymous 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 (1997). All Rights Reserved.

版权所有(C)互联网协会(1997年)。版权所有。

Abstract

摘要

It is common practice on the Internet 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 optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework.

允许匿名访问各种服务是互联网上的常见做法。传统上,这是通过纯文本密码机制完成的,使用“匿名”作为用户名,使用可选跟踪信息(如电子邮件地址)作为密码。由于新的IETF协议不允许明文登录命令,因此需要在SASL[SASL]框架的上下文中提供匿名登录的新方法。

1. Conventions Used in this Document
1. 本文件中使用的公约

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].

本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照“RFC中用于指示需求水平的关键词”中的定义进行解释[关键词]。

2. Anonymous SASL mechanism
2. 匿名SASL机制

The mechanism name associated with anonymous access is "ANONYMOUS". The mechanism consists of a single message from the client to the server. The client sends optional trace information in the form of a human readable string. The trace information should take one of three forms: an Internet email address, an opaque string which does not contain the '@' character and can be interpreted by the system administrator of the client's domain, or nothing. For privacy reasons, an Internet email address should only be used with permission from the user.

与匿名访问关联的机制名称为“匿名”。该机制由从客户端到服务器的单个消息组成。客户端以可读字符串的形式发送可选跟踪信息。跟踪信息应采用以下三种形式之一:Internet电子邮件地址、不包含“@”字符且可由客户端域的系统管理员解释的不透明字符串,或不包含任何内容。出于隐私原因,互联网电子邮件地址只能在获得用户许可的情况下使用。

A server which permits anonymous access will announce support for the ANONYMOUS mechanism, and allow anyone to log in using that mechanism, usually with restricted access.

允许匿名访问的服务器将宣布对匿名机制的支持,并允许任何人使用该机制登录,通常访问受限。

The formal grammar for the client message using Augmented BNF [ABNF] follows.

使用增广BNF[ABNF]的客户机消息的形式语法如下所示。

   message         = [email / token]
        
   message         = [email / token]
        
   TCHAR           = %x20-3F / %x41-7E
                     ;; any printable US-ASCII character except '@'
        
   TCHAR           = %x20-3F / %x41-7E
                     ;; any printable US-ASCII character except '@'
        
   email           = addr-spec
                     ;; as defined in [IMAIL], except with no free
                     ;; insertion of linear-white-space, and the
                     ;; local-part MUST either be entirely enclosed in
                     ;; quotes or entirely unquoted
        
   email           = addr-spec
                     ;; as defined in [IMAIL], except with no free
                     ;; insertion of linear-white-space, and the
                     ;; local-part MUST either be entirely enclosed in
                     ;; quotes or entirely unquoted
        
   token           = 1*255TCHAR
        
   token           = 1*255TCHAR
        
3. Example
3. 实例

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. Newer profiles of SASL will include the client message with the AUTHENTICATE command itself so the extra round trip below (the server response with an empty "+ ") can be eliminated.

请注意,此示例使用SASL的IMAP配置文件[IMAP4]。质询和响应的base64编码以及响应前的“+”是IMAP4配置文件的一部分,而不是SASL本身的一部分。较新的SASL配置文件将包含带有AUTHENTICATE命令本身的客户机消息,因此可以消除下面额外的往返(服务器响应带有空“+”)。

In this example, the user's opaque identification token is "sirhc".

在此示例中,用户的不透明标识令牌为“sircc”。

        S: * OK IMAP4 server ready
        C: A001 CAPABILITY
        S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-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=CRAM-MD5 AUTH=ANONYMOUS
        S: A001 OK done
        C: A002 AUTHENTICATE ANONYMOUS
        S: +
        C: c2lyaGM=
        S: A003 OK Welcome, trace information has been logged.
        
4. Security Considerations
4. 安全考虑

The anonymous mechanism grants access to information by anyone. For this reason it should be disabled by default so 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 anonymously exchange information. Servers which accept anonymous submissions should implement the common "drop box" model which forbids anonymous read access to the area where anonymous submissions are accepted.

如果匿名用户具有对同一区域的读写访问权限,则服务器可以用作匿名交换信息的通信机制。接受匿名提交的服务器应实现公共“下拉框”模型,该模型禁止匿名读取接受匿名提交的区域。

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 limit the number of anonymous users and reduce their priority or limit their resource usage.

如果匿名用户可以运行许多昂贵的操作(例如,IMAP SEARCH BODY命令),这可能会导致拒绝服务攻击。鼓励服务器限制匿名用户的数量,降低其优先级或限制其资源使用。

If there is no idle timeout for the anonymous user and there is a limit on the number of anonymous users, a denial of service attack is enabled. Servers should implement an idle timeout for anonymous users.

如果匿名用户没有空闲超时,并且对匿名用户的数量有限制,则会启用拒绝服务攻击。服务器应该为匿名用户实现空闲超时。

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 trying to trace abuse need to realize this information may be falsified.

跟踪信息未经过身份验证,因此可能被伪造。这可能被用作试图让其他人在访问可疑信息时遇到麻烦。试图追踪滥用的管理员需要意识到这些信息可能是伪造的。

A client which uses the user's correct email address as trace information without explicit permission may violate that user's privacy. Information about who accesses an anonymous archive on a sensitive subject (e.g., sexual abuse) has strong privacy needs. Clients should not send the email address without explicit permission of the user and should offer the option of supplying no trace token -- thus only exposing the source IP address and time. Anonymous proxy servers could enhance this privacy, but would have to consider the resulting potential denial of service attacks.

未经明确许可而将用户的正确电子邮件地址用作跟踪信息的客户端可能会侵犯该用户的隐私。关于谁访问敏感主题(如性虐待)的匿名档案的信息具有强烈的隐私需求。未经用户明确许可,客户端不应发送电子邮件地址,并应提供不提供跟踪令牌的选项,从而仅公开源IP地址和时间。匿名代理服务器可以增强这种隐私,但必须考虑由此产生的潜在拒绝服务攻击。

Anonymous connections are susceptible to man in the middle attacks which view or alter the data transferred. Clients and servers are encouraged to support external integrity and encryption mechanisms.

匿名连接易受中间人攻击,这些攻击查看或更改所传输的数据。鼓励客户端和服务器支持外部完整性和加密机制。

Protocols which fail to require an explicit anonymous login are more susceptible to break-ins given certain common implementation techniques. Specifically, Unix servers which offer user login may

鉴于某些常见的实现技术,不需要显式匿名登录的协议更容易被入侵。具体来说,提供用户登录的Unix服务器可能

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 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 which offer restricted data access should not allow anonymous data access without an explicit login step.

最初以root用户身份启动,并在显式登录命令后切换到相应的用户id。通常,此类服务器在显式登录之前拒绝所有数据访问命令,并且可能会为匿名用户进入受限制的安全环境(例如Unix chroot函数)。如果未明确请求匿名访问,则整个数据访问机制将受到外部安全攻击,而没有明确的保护措施。提供受限数据访问的协议不应允许在没有显式登录步骤的情况下进行匿名数据访问。

5. References
5. 工具书类

[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[ABNF]Crocker,D.和P.Overell,“语法规范的扩充BNF:ABNF”,RFC 2234,1997年11月。

[IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text Messages", STD 11, RFC 822, August 1982.

[IMAIL]Crocker,D.,“Arpa互联网文本信息格式标准”,STD 11,RFC 822,1982年8月。

[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.

[IMAP4]Crispin,M.,“互联网消息访问协议-版本4rev1”,RFC20601996年12月。

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.

[关键词]Bradner,S.,“RFC中用于表示需求水平的关键词”,RFC 211997年3月。

[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.

[SASL]迈尔斯,J.,“简单认证和安全层(SASL)”,RFC22221997年10月。

6. Author's Address
6. 作者地址

Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA

Chris Newman Innosoft International,Inc.美国加利福尼亚州西科维纳湖大道1050号,邮编:91790

   Email: chris.newman@innosoft.com
        
   Email: chris.newman@innosoft.com
        
7. Full Copyright Statement
7. 完整版权声明

Copyright (C) The Internet Society (1997). All Rights Reserved.

版权所有(C)互联网协会(1997年)。版权所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

本文件及其译本可复制并提供给他人,对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文件本身,例如删除版权通知或对互联网协会或其他互联网组织的引用,除非出于制定互联网标准的需要,在这种情况下,必须遵循互联网标准过程中定义的版权程序,或根据需要将其翻译成英语以外的其他语言。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。