Edit File: draft-ietf-sasl-anon-xx.txt
INTERNET-DRAFT Editor: Kurt D. Zeilenga Intended Category: Standards Track OpenLDAP Foundation Expires in six months 30 June 2003 Obsoletes: RFC 2245 The Anonymous SASL Mechanism <draft-ietf-sasl-anon-02.txt> Status of Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is intended to be, after appropriate review and revision, submitted to the RFC Editor as a Standards Track document. Distribution of this memo is unlimited. Technical discussion of this document will take place on the IETF SASL mailing list <ietf-sasl@imc.org>. Please send editorial comments directly to the document editor <Kurt@OpenLDAP.org>. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of Internet-Draft Shadow Directories can be accessed at <http://www.ietf.org/shadow.html>. Copyright (C) The Internet Society (2003). All Rights Reserved. Please see the Full Copyright section near the end of this document for more information. 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 plain text login commands are not permitted in new IETF protocols, a Zeilenga Anonymous SASL Mechanism [Page 1] INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. Conventions 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]. 1. Anonymous SASL mechanism This document defines an anonymous mechanism for the Simple Authentication and Security Layer ([SASL]) framework. The name associated with this mechanism is "ANONYMOUS". This document replaces RFC 2245. Changes since RFC 2245 are detailed in Appendix A. The mechanism consists of a single message from the client to the server. The client sends optional 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 2 of this document. The trace information, which has no semantical value, should take one of three forms: an Internet email address, an opaque string which does not contain the '@' (U+0040) character and can be interpreted by the system administrator of the client's domain, or nothing. For privacy reasons, an Internet email address or other information identifying the user should only be used with permission from the user. 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. This mechanism does not provide a security layer. A formal grammar for the client message using Augmented BNF [ABNF] is provide below as a tool for understanding this technical specification. message = [ email / token ] ;; MUST be prepared in accordance with Section 2 UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040) UTF2 = %xC2-DF UTF0 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / Zeilenga Anonymous SASL Mechanism [Page 2] INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 %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) 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 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 long as 1020 octets. 2. The "trace" profile of "Stringprep" This section defines the "trace" profile of [StringPrep]. This profile is designed for use with the SASL ANONYMOUS Mechanism. Specifically, the client MUST prepare the <message> production in accordance with this profile. The character repertoire of this profile is Unicode 3.2 [Unicode]. No mapping is required by this profile. No Unicode normalization is required by this profile. The list of unassigned code points for this profile is that provided in appendix A of [RFC 3454]. Unassigned code points are not prohibited. Characters from the following tables of [StringPrep] are prohibited: - 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) Zeilenga Anonymous SASL Mechanism [Page 3] INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 - C.9 (Tagging characters) No additional characters are prohibited. This profile requires bidirectional character checking per Section 6 of [StringPrep]. 3. Example 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. 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. In this example, the user's opaque identification token is "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. 4. Security Considerations 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 Zeilenga Anonymous SASL Mechanism [Page 4] INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 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 reduce the priority of anonymous users or limit their resource usage. While servers may impose a limit on the number of anonymous users, it is noted 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 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. 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 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 which offer restricted data access should not allow anonymous data access without an explicit login step. General [SASL] security considerations apply to this mechanism. [StringPrep] security considerations as well as [Unicode] security considerations discussed in [StringPrep] apply to this mechanism. Zeilenga Anonymous SASL Mechanism [Page 5] INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 [UTF-8] security considerations also apply. 5. IANA Considerations It is requested that the SASL Mechanism registry [IANA-SASL] entry for the ANONYMOUS mechanism be updated to reflect that this document now provides its technical specification. To: iana@iana.org Subject: Updated Registration of SASL mechanism ANONYMOUS SASL mechanism name: ANONYMOUS Security considerations: See RFC XXXX. Published specification (optional, recommended): RFC XXXX Person & email address to contact for further information: Kurt Zeilenga <kurt@openldap.org> Chris Neuman <chris.newman@innosoft.com> Intended usage: COMMON Author/Change controller: IESG <iesg@ietf.org> Note: Updates existing entry for ANONYMOUS It is requested that the [Stringprep] profile "trace", first defined in this RFC, be registered: To: iana@iana.org Subject: Initial Registration of Stringprep "trace" profile Stringprep profile: trace Published specification: RFC XXXX Person & email address to contact for further information: Kurt Zeilenga <kurt@openldap.org> 6. Acknowledgment This document is a revision of RFC 2245 by Chris Newman. Portions of the grammar defined in Section 1 were borrowed from [UTF-8] by Francois Yergeau. This document is a product of the IETF SASL WG. 7. Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Zeilenga Anonymous SASL Mechanism [Page 6] INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text Messages", STD 11, RFC 822, August 1982. [Keywords] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", draft-myers-saslrev-xx.txt, a work in progress. [StringPrep] Hoffman P. and M. Blanchet, "Preparation of Internationalized Strings ('stringprep')", RFC 3454, December 2002. [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/). [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", draft-yergeau-rfc2279bis, a work in progress. 8. Informative References [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996. [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS", http://www.iana.org/assignments/sasl- mechanisms. 9. Editor's Address Kurt Zeilenga OpenLDAP Foundation Email: kurt@OpenLDAP.org Appendix A. Changes since RFC 2245 This appendix is non-normative. Zeilenga Anonymous SASL Mechanism [Page 7] INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 RFC 2245 allows the client to send 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. Additionally, a number of editorial changes were made. Intellectual Property Rights The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published 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 Zeilenga Anonymous SASL Mechanism [Page 8] INTERNET-DRAFT draft-ietf-sasl-anon-02.txt 30 June 2003 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. Zeilenga Anonymous SASL Mechanism [Page 9]