| blob | 6934d0d5350cc6676d39be94116275f27635da65 |
7 INTERNET-DRAFT Editor: Kurt D. Zeilenga
8 Intended Category: Standards Track OpenLDAP Foundation
9 Expires in six months 23 June 2002
10 Obsoletes: RFC 2245
14 Anonymous SASL Mechanism
15 <draft-zeilenga-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]
59 \f
60 INTERNET-DRAFT draft-zeilenga-sasl-anon-00.txt 23 June 2002
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 1. Anonymous SASL mechanism
70 This document defines an anonymous mechanism for the Simple
71 Authentication and Security Layer ([SASL]) framework. This document
72 replaces RFC 2245. Changes since RFC 2245 are detailed in Appendix A.
74 The mechanism name associated with anonymous access is "ANONYMOUS".
76 The mechanism consists of a single message from the client to the
77 server. The client sends optional trace information in the form of a
78 human readable string of UTF-8 [UTF8] encoded characters from the
79 Universal Character Set ([UCS]) characters. The trace information
80 should take one of three forms: an Internet email address, an opaque
81 string which does not contain the '@' (U+0040) character and can be
82 interpreted by the system administrator of the client's domain, or
83 nothing. For privacy reasons, an Internet email address should only
84 be used with permission from the user.
86 A server which permits anonymous access will announce support for the
87 ANONYMOUS mechanism, and allow anyone to log in using that mechanism,
88 usually with restricted access.
90 The formal grammar for the client message using Augmented BNF [ABNF]
91 follows.
93 message = [email / token]
95 UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040)
96 UTF2 = %xC0-DF 1(UTF0)
97 UTF3 = %xE0-EF 2(UTF0)
98 UTF4 = %xF0-F7 3(UTF0)
99 UTF5 = %xF8-FB 4(UTF0)
100 UTF6 = %xFC-FD 5(UTF0)
101 UTF0 = %x80-BF
103 TCHAR = UTF1 / UTF2 / UTF3 / UTF3 / UTF4 / UTF5 / UTF6
104 ;; any printable UTF-8 encoded UCS character
105 ;; except '@' (U+0040)
107 email = addr-spec
108 ;; as defined in [IMAIL], except with no free
109 ;; insertion of linear-white-space, and the
110 ;; local-part MUST either be entirely enclosed in
114 Zeilenga Anonymous SASL Mechanism [Page 2]
115 \f
116 INTERNET-DRAFT draft-zeilenga-sasl-anon-00.txt 23 June 2002
119 ;; quotes or entirely unquoted
121 token = 1*255TCHAR
123 The following characters are considered non-printable:
124 - control characters: U+0000..U+001F, U+007F..U+009F;
125 - replacement character: U+FFFD; and
126 - special characters and noncharacter: U+FEFF, U+FFFE, U+FFFF.
129 2. Example
131 Here is a sample ANONYMOUS login between an IMAP client and server.
132 In this example, "C:" and "S:" indicate lines sent by the client and
133 server respectively. If such lines are wrapped without a new "C:" or
134 "S:" label, then the wrapping is for editorial clarity and is not part
135 of the command.
137 Note that this example uses the IMAP profile [IMAP4] of SASL. The
138 base64 encoding of challenges and responses, as well as the "+ "
139 preceding the responses are part of the IMAP4 profile, not part of
140 SASL itself. Newer profiles of SASL will include the client message
141 with the AUTHENTICATE command itself so the extra round trip below
142 (the server response with an empty "+ ") can be eliminated.
144 In this example, the user's opaque identification token is "sirhc".
146 S: * OK IMAP4 server ready
147 C: A001 CAPABILITY
148 S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=ANONYMOUS
149 S: A001 OK done
150 C: A002 AUTHENTICATE ANONYMOUS
151 S: +
152 C: c2lyaGM=
153 S: A003 OK Welcome, trace information has been logged.
156 3. Security Considerations
158 The ANONYMOUS mechanism grants access to information by anyone. For
159 this reason it should be disabled by default so the administrator can
160 make an explicit decision to enable it.
162 If the anonymous user has any write privileges, a denial of service
163 attack is possible by filling up all available space. This can be
164 prevented by disabling all write access by anonymous users.
166 If anonymous users have read and write access to the same area, the
170 Zeilenga Anonymous SASL Mechanism [Page 3]
171 \f
172 INTERNET-DRAFT draft-zeilenga-sasl-anon-00.txt 23 June 2002
175 server can be used as a communication mechanism to anonymously
176 exchange information. Servers which accept anonymous submissions
177 should implement the common "drop box" model which forbids anonymous
178 read access to the area where anonymous submissions are accepted.
180 If the anonymous user can run many expensive operations (e.g., an IMAP
181 SEARCH BODY command), this could enable a denial of service attack.
182 Servers are encouraged to limit the number of anonymous users and
183 reduce their priority or limit their resource usage.
185 If there is no idle timeout for the anonymous user and there is a
186 limit on the number of anonymous users, a denial of service attack is
187 enabled. Servers should implement an idle timeout for anonymous
188 users.
190 The trace information is not authenticated so it can be falsified.
191 This can be used as an attempt to get someone else in trouble for
192 access to questionable information. Administrators trying to trace
193 abuse need to realize this information may be falsified.
195 A client which uses the user's correct email address as trace
196 information without explicit permission may violate that user's
197 privacy. Information about who accesses an anonymous archive on a
198 sensitive subject (e.g., sexual abuse) has strong privacy needs.
199 Clients should not send the email address without explicit permission
200 of the user and should offer the option of supplying no trace token --
201 thus only exposing the source IP address and time. Anonymous proxy
202 servers could enhance this privacy, but would have to consider the
203 resulting potential denial of service attacks.
205 Anonymous connections are susceptible to man in the middle attacks
206 which view or alter the data transferred. Clients and servers are
207 encouraged to support external integrity and encryption mechanisms.
209 Protocols which fail to require an explicit anonymous login are more
210 susceptible to break-ins given certain common implementation
211 techniques. Specifically, Unix servers which offer user login may
212 initially start up as root and switch to the appropriate user id after
213 an explicit login command. Normally such servers refuse all data
214 access commands prior to explicit login and may enter a restricted
215 security environment (e.g., the Unix chroot(2) function) for anonymous
216 users. If anonymous access is not explicitly requested, the entire
217 data access machinery is exposed to external security attacks without
218 the chance for explicit protective measures. Protocols which offer
219 restricted data access should not allow anonymous data access without
220 an explicit login step.
226 Zeilenga Anonymous SASL Mechanism [Page 4]
227 \f
228 INTERNET-DRAFT draft-zeilenga-sasl-anon-00.txt 23 June 2002
231 4. IANA Considerations
233 It is requested that the SASL Mechanism registry [IANA-SASL] entry for
234 the ANONYMOUS mechanism be updated to reflect that this document now
235 provides its technical specification.
237 To: iana@iana.org
238 Subject: Updated Registration of SASL mechanism ANONYMOUS
240 SASL mechanism name: ANONYMOUS
241 Security considerations: See RFC XXXX.
242 Published specification (optional, recommended): RFC XXXX
243 Person & email address to contact for further information:
244 Kurt Zeilenga <kurt@openldap.org>
245 Chris Neuman <chris.newman@innosoft.com>
246 Intended usage: COMMON
247 Author/Change controller: IESG <iesg@ietf.org>
248 Note: Updates existing entry for ANONYMOUS
251 5. Acknowledgement
253 This document is a revision of RFC 2245 by Chris Newman.
256 6. Normative References
258 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
259 Specifications: ABNF", RFC 2234, November 1997.
261 [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet
262 Text Messages", STD 11, RFC 822, August 1982.
264 [SASL] Myers, J., "Simple Authentication and Security Layer
265 (SASL)", RFC 2222bis (a work in progress).
267 [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
268 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
269 : 1993.
271 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
272 10646", RFC 2279, January 1998.
275 7. Informative References
277 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
278 4rev1", RFC 2060, December 1996.
282 Zeilenga Anonymous SASL Mechanism [Page 5]
283 \f
284 INTERNET-DRAFT draft-zeilenga-sasl-anon-00.txt 23 June 2002
287 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
288 MECHANISMS", http://www.iana.org/assignments/sasl-
289 mechanisms.
292 8. Editor's Address
294 Kurt Zeilenga
295 OpenLDAP Foundation
297 Email: kurt@OpenLDAP.org
300 Appendix A. Changes since RFC 2245
302 RFC 2245 allows the client to send optional trace information in the
303 form of a human readable string, but did not define the character
304 encoding nor character set to be used. This document mandates use of
305 UTF-8 encoded UCS characters. The grammar was updated to reflect
306 this.
308 Additionally, a number of editorial changes were made.
311 Full Copyright Statement
313 Copyright 2002, The Internet Society. All Rights Reserved.
315 This document and translations of it may be copied and furnished to
316 others, and derivative works that comment on or otherwise explain it
317 or assist in its implementation may be prepared, copied, published and
318 distributed, in whole or in part, without restriction of any kind,
319 provided that the above copyright notice and this paragraph are
320 included on all such copies and derivative works. However, this
321 document itself may not be modified in any way, such as by removing
322 the copyright notice or references to the Internet Society or other
323 Internet organizations, except as needed for the purpose of
324 developing Internet standards in which case the procedures for
325 copyrights defined in the Internet Standards process must be followed,
326 or as required to translate it into languages other than English.
328 The limited permissions granted above are perpetual and will not be
329 revoked by the Internet Society or its successors or assigns.
331 This document and the information contained herein is provided on an
332 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
333 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
334 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
338 Zeilenga Anonymous SASL Mechanism [Page 6]
339 \f
340 INTERNET-DRAFT draft-zeilenga-sasl-anon-00.txt 23 June 2002
343 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
344 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
394 Zeilenga Anonymous SASL Mechanism [Page 7]
395 \f