Add.
[libidn.git] / draft-ietf-sasl-anon-00.txt
blob16d2309a8b40d78f59d608add5180bd07de745c0
7 INTERNET-DRAFT                           Editor: Kurt D. Zeilenga
8 Intended Category: Standards Track            OpenLDAP Foundation
9 Expires in six months                              8 January 2003
10 Obsoletes: RFC 2245
14                        The Anonymous SASL Mechanism
15                       <draft-ietf-sasl-anon-00.txt>
18 Status of Memo
20   This document is an Internet-Draft and is in full conformance with all
21   provisions of Section 10 of RFC2026.
23   This document is intended to be, after appropriate review and
24   revision, submitted to the RFC Editor as a Standards Track document.
25   Distribution of this memo is unlimited.  Technical discussion of this
26   document will take place on the IETF SASL mailing list
27   <ietf-sasl@imc.org>.  Please send editorial comments directly to the
28   document editor <Kurt@OpenLDAP.org>.
30   Internet-Drafts are working documents of the Internet Engineering Task
31   Force (IETF), its areas, and its working groups.  Note that other
32   groups may also distribute working documents as Internet-Drafts.
33   Internet-Drafts are draft documents valid for a maximum of six months
34   and may be updated, replaced, or obsoleted by other documents at any
35   time.  It is inappropriate to use Internet-Drafts as reference
36   material or to cite them other than as ``work in progress.''
38   The list of current Internet-Drafts can be accessed at
39   <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
40   Internet-Draft Shadow Directories can be accessed at
41   <http://www.ietf.org/shadow.html>.
43   Copyright 2002, The Internet Society.  All Rights Reserved.
45   Please see the Copyright section near the end of this document for
46   more information.
49 Abstract
51   It is common practice on the Internet to permit anonymous access to
52   various services.  Traditionally, this has been done with a plain text
53   password mechanism using "anonymous" as the user name and optional
54   trace information, such as an email address, as the password.  As
58 Zeilenga                Anonymous SASL Mechanism                [Page 1]
60 INTERNET-DRAFT         draft-ietf-sasl-anon-00.txt        8 January 2003
63   plaintext login commands are not permitted in new IETF protocols, a
64   new way to provide anonymous login is needed within the context of the
65   Simple Authentication and Security Layer (SASL) framework.
68 Conventions
70   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
71   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
72   document are to be interpreted as described in [KEYWORDS].
75 1. Anonymous SASL mechanism
77   This document defines an anonymous mechanism for the Simple
78   Authentication and Security Layer ([SASL]) framework.  The name
79   associated with this mechanism is "ANONYMOUS".
81   This document replaces RFC 2245.  Changes since RFC 2245 are detailed
82   in Appendix A.
84   The mechanism consists of a single message from the client to the
85   server.  The client sends optional trace information in the form of a
86   string of [UTF-8] encoded [Unicode] characters prepared in accordance
87   with [Stringprep] and the "plain" stringprep profile defined in
88   Section 2 of this document.  The trace information should take one of
89   three forms: an Internet email address, an opaque string which does
90   not contain the '@' (U+0040) character and can be interpreted by the
91   system administrator of the client's domain, or nothing.  For privacy
92   reasons, an Internet email address or other information identifying
93   the user should only be used with permission from the user.
95   A server which permits anonymous access will announce support for the
96   ANONYMOUS mechanism, and allow anyone to log in using that mechanism,
97   usually with restricted access.
99   This mechanism does not provide a security layer.
101   The formal grammar for the client message using Augmented BNF [ABNF]
102   follows.
104       message     = [ email / token ]
105                        ;; MUST be prepared in accordance with Section 2
107       UTF1        = %x00-3F / %x41-7F ;; less '@' (U+0040)
108       UTF2        = %xC0-DF 1(UTF0)
109       UTF3        = %xE0-EF 2(UTF0)
110       UTF4        = %xF0-F7 3(UTF0)
114 Zeilenga                Anonymous SASL Mechanism                [Page 2]
116 INTERNET-DRAFT         draft-ietf-sasl-anon-00.txt        8 January 2003
119       UTF5        = %xF8-FB 4(UTF0)
120       UTF6        = %xFC-FD 5(UTF0)
121       UTF0        = %x80-BF
123       TCHAR       = UTF1 / UTF2 / UTF3 / UTF3 / UTF4 / UTF5 / UTF6
124                     ;; any UTF-8 encoded Unicode character
125                     ;; except '@' (U+0040)
127       email       = addr-spec
128                     ;; as defined in [IMAIL], except with no free
129                     ;; insertion of linear-white-space, and the
130                     ;; local-part MUST either be entirely enclosed in
131                     ;; quotes or entirely unquoted
133       token       = 1*255TCHAR
135       Note to implementors:
136       The <token> production is restricted to 255 UTF-8 encoded
137       characters.  As the encoding of a characters use a sequence of 1
138       to 6 octets, a token may be long as 1530 octets.
140 2. The plain "stringprep" profile
142   This section defines the "plain" profile of [Stringprep].  This
143   profile is designed for use with the SASL ANONYMOUS Mechanism.
144   Specifically, the client MUST prepare the <message> production in
145   accordance with this profile.
147   The character repertiore of this profile is Unicode 3.2 [Unicode].
149   No mapping is required by this profile.
151   No Unicode normalization is required by this profile.
153   Characters from the following tables of [Stringprep] are prohibited:
154       - C.2.1 (ASCII control characters)
155       - C.2.2 (Non-ASCII control characters)
156       - C.3 (Private use characters)
157       - C.4 (Non-character code points)
158       - C.5 (Surrogate codes)
159       - C.6 (Inappropriate for plain text)
160       - C.8 (Change display properties or are deprecated)
161       - C.9 (Tagging characters)
163   No additional characters are prohibited.
165   This profile requires bidirectional character checking per Section 6
166   of [Stringprep].
170 Zeilenga                Anonymous SASL Mechanism                [Page 3]
172 INTERNET-DRAFT         draft-ietf-sasl-anon-00.txt        8 January 2003
175 3. Example
177   Here is a sample ANONYMOUS login between an IMAP client and server.
178   In this example, "C:" and "S:" indicate lines sent by the client and
179   server respectively.  If such lines are wrapped without a new "C:" or
180   "S:" label, then the wrapping is for editorial clarity and is not part
181   of the command.
183   Note that this example uses the IMAP profile [IMAP4] of SASL.  The
184   base64 encoding of challenges and responses, as well as the "+ "
185   preceding the responses are part of the IMAP4 profile, not part of
186   SASL itself.  Newer profiles of SASL will include the client message
187   with the AUTHENTICATE command itself so the extra round trip below
188   (the server response with an empty "+ ") can be eliminated.
190   In this example, the user's opaque identification token is "sirhc".
192       S: * OK IMAP4 server ready
193       C: A001 CAPABILITY
194       S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=ANONYMOUS
195       S: A001 OK done
196       C: A002 AUTHENTICATE ANONYMOUS
197       S: +
198       C: c2lyaGM=
199       S: A003 OK Welcome, trace information has been logged.
202 4. Security Considerations
204   The ANONYMOUS mechanism grants access to information by anyone.  For
205   this reason it should be disabled by default so the administrator can
206   make an explicit decision to enable it.
208   If the anonymous user has any write privileges, a denial of service
209   attack is possible by filling up all available space.  This can be
210   prevented by disabling all write access by anonymous users.
212   If anonymous users have read and write access to the same area, the
213   server can be used as a communication mechanism to anonymously
214   exchange information.  Servers which accept anonymous submissions
215   should implement the common "drop box" model which forbids anonymous
216   read access to the area where anonymous submissions are accepted.
218   If the anonymous user can run many expensive operations (e.g., an IMAP
219   SEARCH BODY command), this could enable a denial of service attack.
220   Servers are encouraged to limit the number of anonymous users and
221   reduce their priority or limit their resource usage.
226 Zeilenga                Anonymous SASL Mechanism                [Page 4]
228 INTERNET-DRAFT         draft-ietf-sasl-anon-00.txt        8 January 2003
231   If there is no idle timeout for the anonymous user and there is a
232   limit on the number of anonymous users, a denial of service attack is
233   enabled.  Servers should implement an idle timeout for anonymous
234   users.
236   The trace information is not authenticated so it can be falsified.
237   This can be used as an attempt to get someone else in trouble for
238   access to questionable information.  Administrators trying to trace
239   abuse need to realize this information may be falsified.
241   A client which uses the user's correct email address as trace
242   information without explicit permission may violate that user's
243   privacy.  Information about who accesses an anonymous archive on a
244   sensitive subject (e.g., sexual abuse) has strong privacy needs.
245   Clients should not send the email address without explicit permission
246   of the user and should offer the option of supplying no trace token --
247   thus only exposing the source IP address and time.  Anonymous proxy
248   servers could enhance this privacy, but would have to consider the
249   resulting potential denial of service attacks.
251   Anonymous connections are susceptible to man in the middle attacks
252   which view or alter the data transferred.  Clients and servers are
253   encouraged to support external integrity and encryption mechanisms.
255   Protocols which fail to require an explicit anonymous login are more
256   susceptible to break-ins given certain common implementation
257   techniques.  Specifically, Unix servers which offer user login may
258   initially start up as root and switch to the appropriate user id after
259   an explicit login command.  Normally such servers refuse all data
260   access commands prior to explicit login and may enter a restricted
261   security environment (e.g., the Unix chroot(2) function) for anonymous
262   users.  If anonymous access is not explicitly requested, the entire
263   data access machinery is exposed to external security attacks without
264   the chance for explicit protective measures.  Protocols which offer
265   restricted data access should not allow anonymous data access without
266   an explicit login step.
268   General [SASL] security considerations apply to this mechanism.
270   [Stringprep] security considerations as well as [Unicode], security
271   considerations discussed in [Stringprep], apply to this mechanism.
274 5. IANA Considerations
276   It is requested that the SASL Mechanism registry [IANA-SASL] entry for
277   the ANONYMOUS mechanism be updated to reflect that this document now
278   provides its technical specification.
282 Zeilenga                Anonymous SASL Mechanism                [Page 5]
284 INTERNET-DRAFT         draft-ietf-sasl-anon-00.txt        8 January 2003
287       To: iana@iana.org
288       Subject: Updated Registration of SASL mechanism ANONYMOUS
290       SASL mechanism name: ANONYMOUS
291       Security considerations: See RFC XXXX.
292       Published specification (optional, recommended): RFC XXXX
293       Person & email address to contact for further information:
294            Kurt Zeilenga <kurt@openldap.org>
295            Chris Neuman <chris.newman@innosoft.com>
296       Intended usage: COMMON
297       Author/Change controller: IESG <iesg@ietf.org>
298       Note: Updates existing entry for ANONYMOUS
300   It is requested that the "stringprep" [RFC3454] profile "plain", first
301   defined in this RFC, be registered:
303       To: iana@iana.org
304       Subject: Initial Registration of Stringprep "plain" profile
306       Stringprep profile: plain
307       Published specification: RFC XXXX
308       Person & email address to contact for further information:
309           Kurt Zeilenga <kurt@openldap.org>
312 6. Acknowledgement
314   This document is a revision of RFC 2245 by Chris Newman.
317 7. Normative References
319   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
320                Specifications: ABNF", RFC 2234, November 1997.
322   [IMAIL]      Crocker, D., "Standard for the Format of Arpa Internet
323                Text Messages", STD 11, RFC 822, August 1982.
325   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
326                Requirement Levels", BCP 14, RFC 2119, March 1997
328   [SASL]       Myers, J., "Simple Authentication and Security Layer
329                (SASL)", RFC 2222bis (a work in progress).
331   [Stringprep] P. Hoffman, M. Blanchet, "Preparation of
332                Internationalized Strings ('stringprep')", RFC 3454,
333                December 2002.
338 Zeilenga                Anonymous SASL Mechanism                [Page 6]
340 INTERNET-DRAFT         draft-ietf-sasl-anon-00.txt        8 January 2003
343   [Unicode]    The Unicode Consortium. The Unicode Standard, Version
344                3.2.0 is defined by The Unicode Standard, Version 3.0
345                (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
346                as amended by the Unicode Standard Annex #27: Unicode 3.1
347                (http://www.unicode.org/reports/tr27/) and by the Unicode
348                Standard Annex #28: Unicode 3.2
349                (http://www.unicode.org/reports/tr28/).
351   [UTF-8]      Yergeau, F., "UTF-8, a transformation format of ISO
352                10646", RFC 2279, January 1998.
355 8. Informative References
357   [IMAP4]      Crispin, M., "Internet Message Access Protocol - Version
358                4rev1", RFC 2060, December 1996.
360   [IANA-SASL]  IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
361                MECHANISMS", http://www.iana.org/assignments/sasl-
362                mechanisms.
365 9. Editor's Address
367   Kurt Zeilenga
368   OpenLDAP Foundation
370   Email: kurt@OpenLDAP.org
373 Appendix A.  Changes since RFC 2245
375   This appendix is non-normative.
377   RFC 2245 allows the client to send optional trace information in the
378   form of a human readable string.  RFC 2245 restricted this string to
379   US-ASCII.  As the Internet is international, this document uses a
380   string restricted to UTF-8 encoded Unicode "plain" characters.  A
381   "stringprep" profile is defined to precisely define which Unicode
382   characters are allowed in this string.  While the string remains
383   restricted to 255 characters, the encoded length of each character may
384   now range from 1 to 6 octets.
386   Additionally, a number of editorial changes were made.
389 Full Copyright Statement
394 Zeilenga                Anonymous SASL Mechanism                [Page 7]
396 INTERNET-DRAFT         draft-ietf-sasl-anon-00.txt        8 January 2003
399   Copyright 2002, The Internet Society.  All Rights Reserved.
401   This document and translations of it may be copied and furnished to
402   others, and derivative works that comment on or otherwise explain it
403   or assist in its implementation may be prepared, copied, published and
404   distributed, in whole or in part, without restriction of any kind,
405   provided that the above copyright notice and this paragraph are
406   included on all such copies and derivative works.  However, this
407   document itself may not be modified in any way, such as by removing
408   the copyright notice or references to the Internet Society or other
409   Internet organizations, except as needed for the  purpose of
410   developing Internet standards in which case the procedures for
411   copyrights defined in the Internet Standards process must be followed,
412   or as required to translate it into languages other than English.
414   The limited permissions granted above are perpetual and will not be
415   revoked by the Internet Society or its successors or assigns.
417   This document and the information contained herein is provided on an
418   "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
419   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
420   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
421   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
422   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
450 Zeilenga                Anonymous SASL Mechanism                [Page 8]