5 INTERNET-DRAFT Editor: Kurt D. Zeilenga
6 Intended Category: Standards Track OpenLDAP Foundation
7 Expires: August 2005 21 February 2005
12 The Anonymous SASL Mechanism
13 <draft-ietf-sasl-anon-05.txt>
19 This document is intended to be, after appropriate review and
20 revision, submitted to the RFC Editor as a Standards Track document.
21 Distribution of this memo is unlimited. Technical discussion of this
22 document will take place on the IETF SASL mailing list
23 <ietf-sasl@imc.org>. Please send editorial comments directly to the
24 document editor <Kurt@OpenLDAP.org>.
26 By submitting this Internet-Draft, I accept the provisions of Section
27 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
28 applicable patent or other IPR claims of which I am aware have been
29 disclosed, or will be disclosed, and any of which I become aware will
30 be disclosed, in accordance with RFC 3668.
32 Internet-Drafts are working documents of the Internet Engineering Task
33 Force (IETF), its areas, and its working groups. Note that other
34 groups may also distribute working documents as Internet-Drafts.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference material
39 or to cite them other than as "work in progress."
41 The list of current Internet-Drafts can be accessed at
42 http://www.ietf.org/1id-abstracts.html
44 The list of Internet-Draft Shadow Directories can be accessed at
45 http://www.ietf.org/shadow.html
48 Copyright (C) The Internet Society (2005). All Rights Reserved.
50 Please see the Full Copyright section near the end of this document
56 Zeilenga Anonymous SASL Mechanism [Page 1]
58 INTERNET-DRAFT draft-ietf-sasl-anon-05.txt 21 February 2005
63 It is common practice on the Internet to permit anonymous access to
64 various services. Traditionally, this has been done with a plain text
65 password mechanism using "anonymous" as the user name and optional
66 trace information, such as an email address, as the password. As
67 plain text login commands are not permitted in new IETF protocols, a
68 new way to provide anonymous login is needed within the context of the
69 Simple Authentication and Security Layer (SASL) framework.
72 1. Anonymous SASL mechanism
74 This document defines an anonymous mechanism for the Simple
75 Authentication and Security Layer ([SASL]) framework. The name
76 associated with this mechanism is "ANONYMOUS".
78 Unlike many other SASL mechanisms whose purpose is to authenticate and
79 identify the user to a server, the purpose of this SASL mechanism is
80 to allow the user to gain access to services or resources without
81 requiring the user to establish or otherwise disclose their identity
82 to the server. That is, this mechanism provides an anonymous login
85 This mechanism does not provide a security layer.
87 This document replaces RFC 2245. Changes since RFC 2245 are detailed
90 The mechanism consists of a single message from the client to the
91 server. The client may include in this message trace information in
92 the form of a string of [UTF-8] encoded [Unicode] characters prepared
93 in accordance with [StringPrep] and the "trace" stringprep profile
94 defined in Section 2 of this document. The trace information, which
95 has no semantical value, should take one of two forms: an Internet
96 email address, an opaque string which does not contain the '@'
97 (U+0040) character and can be interpreted by the system administrator
98 of the client's domain. For privacy reasons, an Internet email
99 address or other information identifying the user should only be used
100 with permission from the user.
102 A server which permits anonymous access will announce support for the
103 ANONYMOUS mechanism, and allow anyone to log in using that mechanism,
104 usually with restricted access.
106 A formal grammar for the client message using Augmented BNF [ABNF] is
107 provide below as a tool for understanding this technical
112 Zeilenga Anonymous SASL Mechanism [Page 2]
114 INTERNET-DRAFT draft-ietf-sasl-anon-05.txt 21 February 2005
117 message = [ email / token ]
118 ;; to be prepared in accordance with Section 2
120 UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040)
122 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
123 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
124 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
128 TCHAR = UTF1 / UTF2 / UTF3 / UTF4
129 ;; any UTF-8 encoded Unicode character
130 ;; except '@' (U+0040)
133 ;; as defined in [IMAIL]
137 Note to implementors:
138 The <token> production is restricted to 255 UTF-8 encoded Unicode
139 characters. As the encoding of a characters uses a sequence of 1
140 to 4 octets, a token may be long as 1020 octets.
143 2. The "trace" profile of "Stringprep"
145 This section defines the "trace" profile of [StringPrep]. This
146 profile is designed for use with the SASL ANONYMOUS Mechanism.
147 Specifically, the client is to prepare the <message> production in
148 accordance with this profile.
150 The character repertoire of this profile is Unicode 3.2 [Unicode].
152 No mapping is required by this profile.
154 No Unicode normalization is required by this profile.
156 The list of unassigned code points for this profile is that provided
157 in appendix A of [StringPrep]. Unassigned code points are not
160 Characters from the following tables of [StringPrep] are prohibited:
161 - C.2.1 (ASCII control characters)
162 - C.2.2 (Non-ASCII control characters)
163 - C.3 (Private use characters)
164 - C.4 (Non-character code points)
168 Zeilenga Anonymous SASL Mechanism [Page 3]
170 INTERNET-DRAFT draft-ietf-sasl-anon-05.txt 21 February 2005
173 - C.5 (Surrogate codes)
174 - C.6 (Inappropriate for plain text)
175 - C.8 (Change display properties are deprecated)
176 - C.9 (Tagging characters)
178 No additional characters are prohibited.
180 This profile requires bidirectional character checking per Section 6
186 Here is a sample ANONYMOUS login between an IMAP client and server.
187 In this example, "C:" and "S:" indicate lines sent by the client and
188 server respectively. If such lines are wrapped without a new "C:" or
189 "S:" label, then the wrapping is for editorial clarity and is not part
192 Note that this example uses the IMAP profile [IMAP4] of SASL. The
193 base64 encoding of challenges and responses, as well as the "+ "
194 preceding the responses are part of the IMAP4 profile, not part of
195 SASL itself. Additionally, protocols with SASL profiles permitting an
196 initial client response will be able to avoid the extra round trip
197 below (the server response with an empty "+ ").
199 In this example, the trace information is "sirhc".
201 S: * OK IMAP4 server ready
203 S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=ANONYMOUS
205 C: A002 AUTHENTICATE ANONYMOUS
208 S: A003 OK Welcome, trace information has been logged.
211 4. Security Considerations
213 The ANONYMOUS mechanism grants access to services and/or resources by
214 anyone. For this reason it should be disabled by default so the
215 administrator can make an explicit decision to enable it.
217 If the anonymous user has any write privileges, a denial of service
218 attack is possible by filling up all available space. This can be
219 prevented by disabling all write access by anonymous users.
224 Zeilenga Anonymous SASL Mechanism [Page 4]
226 INTERNET-DRAFT draft-ietf-sasl-anon-05.txt 21 February 2005
229 If anonymous users have read and write access to the same area, the
230 server can be used as a communication mechanism to anonymously
231 exchange information. Servers which accept anonymous submissions
232 should implement the common "drop box" model which forbids anonymous
233 read access to the area where anonymous submissions are accepted.
235 If the anonymous user can run many expensive operations (e.g., an IMAP
236 SEARCH BODY command), this could enable a denial of service attack.
237 Servers are encouraged to reduce the priority of anonymous users or
238 limit their resource usage.
240 While servers may impose a limit on the number of anonymous users, it
241 is noted that such limits enable denial of service attacks and should
242 be used with caution.
244 The trace information is not authenticated so it can be falsified.
245 This can be used as an attempt to get someone else in trouble for
246 access to questionable information. Administrators investigating
247 abuse need to realize this trace information may be falsified.
249 A client which uses the user's correct email address as trace
250 information without explicit permission may violate that user's
251 privacy. Anyone who accesses an anonymous archive on a sensitive
252 subject (e.g. sexual abuse) likely has strong privacy needs. Clients
253 should not send the email address without explicit permission of the
254 user and should offer the option of supplying no trace information --
255 thus only exposing the source IP address and time. Anonymous proxy
256 servers could enhance this privacy, but would have to consider the
257 resulting potential denial of service attacks.
259 Anonymous connections are susceptible to man-in-the-middle attacks
260 which view or alter the data transferred. Clients and servers are
261 encouraged to support external data security services.
263 Protocols which fail to require an explicit anonymous login are more
264 susceptible to break-ins given certain common implementation
265 techniques. Specifically, Unix servers which offer user login may
266 initially start up as root and switch to the appropriate user id after
267 an explicit login command. Normally such servers refuse all data
268 access commands prior to explicit login and may enter a restricted
269 security environment (e.g., the Unix chroot(2) function) for anonymous
270 users. If anonymous access is not explicitly requested, the entire
271 data access machinery is exposed to external security attacks without
272 the chance for explicit protective measures. Protocols which offer
273 restricted data access should not allow anonymous data access without
274 an explicit login step.
276 General [SASL] security considerations apply to this mechanism.
280 Zeilenga Anonymous SASL Mechanism [Page 5]
282 INTERNET-DRAFT draft-ietf-sasl-anon-05.txt 21 February 2005
285 [StringPrep] security considerations as well as [Unicode] security
286 considerations discussed in [StringPrep] apply to this mechanism.
287 UTF-8 [RFC3629] security considerations also apply.
290 5. IANA Considerations
292 It is requested that the SASL Mechanism registry [IANA-SASL] entry for
293 the ANONYMOUS mechanism be updated to reflect that this document now
294 provides its technical specification.
297 Subject: Updated Registration of SASL mechanism ANONYMOUS
299 SASL mechanism name: ANONYMOUS
300 Security considerations: See RFC XXXX.
301 Published specification (optional, recommended): RFC XXXX
302 Person & email address to contact for further information:
303 Kurt Zeilenga <Kurt@OpenLDAP.org>
304 Chris Newman <Chris.Newman@sun.com>
305 Intended usage: COMMON
306 Author/Change controller: IESG <iesg@ietf.org>
307 Note: Updates existing entry for ANONYMOUS
310 It is requested that the [Stringprep] profile "trace", first defined
311 in this RFC, be registered:
314 Subject: Initial Registration of Stringprep "trace" profile
316 Stringprep profile: trace
317 Published specification: RFC XXXX
318 Person & email address to contact for further information:
319 Kurt Zeilenga <kurt@openldap.org>
324 This document is a revision of RFC 2245 by Chris Newman. Portions of
325 the grammar defined in Section 1 were borrowed from RFC 3629 by
328 This document is a product of the IETF SASL WG.
331 7. Normative References
336 Zeilenga Anonymous SASL Mechanism [Page 6]
338 INTERNET-DRAFT draft-ietf-sasl-anon-05.txt 21 February 2005
341 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
342 Specifications: ABNF", RFC 2234, November 1997.
344 [IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 2822,
347 [SASL] Melnikov, A. (Editor), "Simple Authentication and
348 Security Layer (SASL)",
349 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
351 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
352 Internationalized Strings ('stringprep')", RFC 3454,
355 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
356 3.2.0" is defined by "The Unicode Standard, Version 3.0"
357 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
358 as amended by the "Unicode Standard Annex #27: Unicode
359 3.1" (http://www.unicode.org/reports/tr27/) and by the
360 "Unicode Standard Annex #28: Unicode 3.2"
361 (http://www.unicode.org/reports/tr28/).
363 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
364 10646", RFC 3629 (also STD 63), November 2003.
367 8. Informative References
369 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
370 4rev1", RFC 3501, March 2003.
372 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
374 <http://www.iana.org/assignments/sasl-mechanisms>.
382 Email: Kurt@OpenLDAP.org
385 Appendix A. Changes since RFC 2245
387 This appendix is non-normative.
392 Zeilenga Anonymous SASL Mechanism [Page 7]
394 INTERNET-DRAFT draft-ietf-sasl-anon-05.txt 21 February 2005
397 RFC 2245 allows the client to include optional trace information in
398 the form of a human readable string. RFC 2245 restricted this string
399 to US-ASCII. As the Internet is international, this document uses a
400 string restricted to UTF-8 encoded Unicode characters. A "stringprep"
401 profile is defined to precisely define which Unicode characters are
402 allowed in this string. While the string remains restricted to 255
403 characters, the encoded length of each character may now range from 1
406 Additionally, a number of editorial changes were made.
410 Intellectual Property Rights
412 The IETF takes no position regarding the validity or scope of any
413 Intellectual Property Rights or other rights that might be claimed to
414 pertain to the implementation or use of the technology described in
415 this document or the extent to which any license under such rights
416 might or might not be available; nor does it represent that it has
417 made any independent effort to identify any such rights. Information
418 on the procedures with respect to rights in RFC documents can be found
419 in BCP 78 and BCP 79.
421 Copies of IPR disclosures made to the IETF Secretariat and any
422 assurances of licenses to be made available, or the result of an
423 attempt made to obtain a general license or permission for the use of
424 such proprietary rights by implementers or users of this specification
425 can be obtained from the IETF on-line IPR repository at
426 http://www.ietf.org/ipr.
428 The IETF invites any interested party to bring to its attention any
429 copyrights, patents or patent applications, or other proprietary
430 rights that may cover technology that may be required to implement
431 this standard. Please address the information to the IETF at
438 Copyright (C) The Internet Society (2005). This document is subject
439 to the rights, licenses and restrictions contained in BCP 78, and
440 except as set forth therein, the authors retain all their rights.
442 This document and the information contained herein are provided on an
443 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
444 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
448 Zeilenga Anonymous SASL Mechanism [Page 8]
450 INTERNET-DRAFT draft-ietf-sasl-anon-05.txt 21 February 2005
453 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
454 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
455 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
456 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
504 Zeilenga Anonymous SASL Mechanism [Page 9]