imapext-2007
view docs/rfc/rfc4505.txt @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line source
7 Network Working Group K. Zeilenga, Ed.
8 Request for Comments: 4505 OpenLDAP Foundation
9 Obsoletes: 2245 June 2006
10 Category: Standards Track
13 Anonymous Simple Authentication and Security Layer (SASL) Mechanism
15 Status of This Memo
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
23 Copyright Notice
25 Copyright (C) The Internet Society (2006).
27 Abstract
29 On the Internet, it is common practice to permit anonymous access to
30 various services. Traditionally, this has been done with a plain-
31 text password mechanism using "anonymous" as the user name and using
32 optional trace information, such as an email address, as the
33 password. As plain-text login commands are not permitted in new IETF
34 protocols, a new way to provide anonymous login is needed within the
35 context of the Simple Authentication and Security Layer (SASL)
36 framework.
38 1. Introduction
40 This document defines an anonymous mechanism for the Simple
41 Authentication and Security Layer ([SASL]) framework. The name
42 associated with this mechanism is "ANONYMOUS".
44 Unlike many other SASL mechanisms, whose purpose is to authenticate
45 and identify the user to a server, the purpose of this SASL mechanism
46 is to allow the user to gain access to services or resources without
47 requiring the user to establish or otherwise disclose their identity
48 to the server. That is, this mechanism provides an anonymous login
49 method.
51 This mechanism does not provide a security layer.
53 This document replaces RFC 2245. Changes since RFC 2245 are detailed
54 in Appendix A.
58 Zeilenga Standards Track [Page 1]
60 RFC 4505 Anonymous SASL Mechanism June 2006
63 2. The Anonymous Mechanism
65 The mechanism consists of a single message from the client to the
66 server. The client may include in this message trace information in
67 the form of a string of [UTF-8]-encoded [Unicode] characters prepared
68 in accordance with [StringPrep] and the "trace" stringprep profile
69 defined in Section 3 of this document. The trace information, which
70 has no semantical value, should take one of two forms: an Internet
71 email address, or an opaque string that does not contain the '@'
72 (U+0040) character and that can be interpreted by the system
73 administrator of the client's domain. For privacy reasons, an
74 Internet email address or other information identifying the user
75 should only be used with permission from the user.
77 A server that permits anonymous access will announce support for the
78 ANONYMOUS mechanism and allow anyone to log in using that mechanism,
79 usually with restricted access.
81 A formal grammar for the client message using Augmented BNF [ABNF] is
82 provided below as a tool for understanding this technical
83 specification.
85 message = [ email / token ]
86 ;; to be prepared in accordance with Section 3
88 UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040)
89 UTF2 = %xC2-DF UTF0
90 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
91 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
92 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
93 %xF4 %x80-8F 2(UTF0)
94 UTF0 = %x80-BF
96 TCHAR = UTF1 / UTF2 / UTF3 / UTF4
97 ;; any UTF-8 encoded Unicode character
98 ;; except '@' (U+0040)
100 email = addr-spec
101 ;; as defined in [IMAIL]
103 token = 1*255TCHAR
105 Note to implementors:
106 The <token> production is restricted to 255 UTF-8-encoded Unicode
107 characters. As the encoding of a characters uses a sequence of 1
108 to 4 octets, a token may be as long as 1020 octets.
114 Zeilenga Standards Track [Page 2]
116 RFC 4505 Anonymous SASL Mechanism June 2006
119 3. The "trace" Profile of "Stringprep"
121 This section defines the "trace" profile of [StringPrep]. This
122 profile is designed for use with the SASL ANONYMOUS Mechanism.
123 Specifically, the client is to prepare the <message> production in
124 accordance with this profile.
126 The character repertoire of this profile is Unicode 3.2 [Unicode].
128 No mapping is required by this profile.
130 No Unicode normalization is required by this profile.
132 The list of unassigned code points for this profile is that provided
133 in Appendix A of [StringPrep]. Unassigned code points are not
134 prohibited.
136 Characters from the following tables of [StringPrep] are prohibited:
138 - C.2.1 (ASCII control characters)
139 - C.2.2 (Non-ASCII control characters)
140 - C.3 (Private use characters)
141 - C.4 (Non-character code points)
142 - C.5 (Surrogate codes)
143 - C.6 (Inappropriate for plain text)
144 - C.8 (Change display properties are deprecated)
145 - C.9 (Tagging characters)
147 No additional characters are prohibited.
149 This profile requires bidirectional character checking per Section 6
150 of [StringPrep].
152 4. Example
154 Here is a sample ANONYMOUS login between an IMAP client and server.
155 In this example, "C:" and "S:" indicate lines sent by the client and
156 server, respectively. If such lines are wrapped without a new "C:"
157 or "S:" label, then the wrapping is for editorial clarity and is not
158 part of the command.
160 Note that this example uses the IMAP profile [IMAP4] of SASL. The
161 base64 encoding of challenges and responses as well as the "+ "
162 preceding the responses are part of the IMAP4 profile, not part of
163 SASL itself. Additionally, protocols with SASL profiles permitting
164 an initial client response will be able to avoid the extra round trip
165 below (the server response with an empty "+ ").
170 Zeilenga Standards Track [Page 3]
172 RFC 4505 Anonymous SASL Mechanism June 2006
175 In this example, the trace information is "sirhc".
177 S: * OK IMAP4 server ready
178 C: A001 CAPABILITY
179 S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=ANONYMOUS
180 S: A001 OK done
181 C: A002 AUTHENTICATE ANONYMOUS
182 S: +
183 C: c2lyaGM=
184 S: A003 OK Welcome, trace information has been logged.
186 5. Security Considerations
188 The ANONYMOUS mechanism grants access to services and/or resources by
189 anyone. For this reason, it should be disabled by default so that
190 the administrator can make an explicit decision to enable it.
192 If the anonymous user has any write privileges, a denial-of-service
193 attack is possible by filling up all available space. This can be
194 prevented by disabling all write access by anonymous users.
196 If anonymous users have read and write access to the same area, the
197 server can be used as a communication mechanism to exchange
198 information anonymously. Servers that accept anonymous submissions
199 should implement the common "drop box" model, which forbids anonymous
200 read access to the area where anonymous submissions are accepted.
202 If the anonymous user can run many expensive operations (e.g., an
203 IMAP SEARCH BODY command), this could enable a denial-of-service
204 attack. Servers are encouraged to reduce the priority of anonymous
205 users or limit their resource usage.
207 While servers may impose a limit on the number of anonymous users,
208 note that such limits enable denial-of-service attacks and should be
209 used with caution.
211 The trace information is not authenticated, so it can be falsified.
212 This can be used as an attempt to get someone else in trouble for
213 access to questionable information. Administrators investigating
214 abuse need to realize that this trace information may be falsified.
216 A client that uses the user's correct email address as trace
217 information without explicit permission may violate that user's
218 privacy. Anyone who accesses an anonymous archive on a sensitive
219 subject (e.g., sexual abuse) likely has strong privacy needs.
220 Clients should not send the email address without the explicit
221 permission of the user and should offer the option of supplying no
222 trace information, thus only exposing the source IP address and time.
226 Zeilenga Standards Track [Page 4]
228 RFC 4505 Anonymous SASL Mechanism June 2006
231 Anonymous proxy servers could enhance this privacy but would have to
232 consider the resulting potential denial-of-service attacks.
234 Anonymous connections are susceptible to man-in-the-middle attacks
235 that view or alter the data transferred. Clients and servers are
236 encouraged to support external data security services.
238 Protocols that fail to require an explicit anonymous login are more
239 susceptible to break-ins given certain common implementation
240 techniques. Specifically, Unix servers that offer user login may
241 initially start up as root and switch to the appropriate user id
242 after an explicit login command. Normally, such servers refuse all
243 data access commands prior to explicit login and may enter a
244 restricted security environment (e.g., the Unix chroot(2) function)
245 for anonymous users. If anonymous access is not explicitly
246 requested, the entire data access machinery is exposed to external
247 security attacks without the chance for explicit protective measures.
248 Protocols that offer restricted data access should not allow
249 anonymous data access without an explicit login step.
251 General [SASL] security considerations apply to this mechanism.
253 [StringPrep] security considerations and [Unicode] security
254 considerations discussed in [StringPrep] apply to this mechanism.
255 [UTF-8] security considerations also apply.
257 6. IANA Considerations
259 The SASL Mechanism registry [IANA-SASL] entry for the ANONYMOUS
260 mechanism has been updated by the IANA to reflect that this document
261 now provides its technical specification.
263 To: iana@iana.org
264 Subject: Updated Registration of SASL mechanism ANONYMOUS
266 SASL mechanism name: ANONYMOUS
267 Security considerations: See RFC 4505.
268 Published specification (optional, recommended): RFC 4505
269 Person & email address to contact for further information:
270 Kurt Zeilenga <Kurt@OpenLDAP.org>
271 Chris Newman <Chris.Newman@sun.com>
272 Intended usage: COMMON
273 Author/Change controller: IESG <iesg@ietf.org>
274 Note: Updates existing entry for ANONYMOUS
282 Zeilenga Standards Track [Page 5]
284 RFC 4505 Anonymous SASL Mechanism June 2006
287 The [StringPrep] profile "trace", first defined in this RFC, has been
288 registered:
290 To: iana@iana.org
291 Subject: Initial Registration of Stringprep "trace" profile
293 Stringprep profile: trace
294 Published specification: RFC 4505
295 Person & email address to contact for further information:
296 Kurt Zeilenga <kurt@openldap.org>
298 7. Acknowledgement
300 This document is a revision of RFC 2245 by Chris Newman. Portions of
301 the grammar defined in Section 1 were borrowed from RFC 3629 by
302 Francois Yergeau.
304 This document is a product of the IETF SASL WG.
306 8. Normative References
308 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
309 Specifications: ABNF", RFC 4234, October 2005.
311 [IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April
312 2001.
314 [SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
315 Authentication and Security Layer (SASL)", RFC 4422,
316 June 2006.
318 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
319 Internationalized Strings ('stringprep')", RFC 3454,
320 December 2002.
322 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
323 3.2.0" is defined by "The Unicode Standard, Version 3.0"
324 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
325 as amended by the "Unicode Standard Annex #27: Unicode
326 3.1" (http://www.unicode.org/reports/tr27/) and by the
327 "Unicode Standard Annex #28: Unicode 3.2"
328 (http://www.unicode.org/reports/tr28/).
330 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
331 10646", RFC 3629 (also STD 63), November 2003.
338 Zeilenga Standards Track [Page 6]
340 RFC 4505 Anonymous SASL Mechanism June 2006
343 9. Informative References
345 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
346 4rev1", RFC 3501, March 2003.
348 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
349 MECHANISMS", <http://www.iana.org/assignments/sasl-
350 mechanisms>.
394 Zeilenga Standards Track [Page 7]
396 RFC 4505 Anonymous SASL Mechanism June 2006
399 Appendix A. Changes since RFC 2245
401 This appendix is non-normative.
403 RFC 2245 allows the client to include optional trace information in
404 the form of a human readable string. RFC 2245 restricted this string
405 to US-ASCII. As the Internet is international, this document uses a
406 string restricted to UTF-8 encoded Unicode characters. A
407 "stringprep" profile is defined to precisely define which Unicode
408 characters are allowed in this string. While the string remains
409 restricted to 255 characters, the encoded length of each character
410 may now range from 1 to 4 octets.
412 Additionally, a number of editorial changes were made.
414 Editor's Address
416 Kurt D. Zeilenga
417 OpenLDAP Foundation
419 EMail: Kurt@OpenLDAP.org
450 Zeilenga Standards Track [Page 8]
452 RFC 4505 Anonymous SASL Mechanism June 2006
455 Full Copyright Statement
457 Copyright (C) The Internet Society (2006).
459 This document is subject to the rights, licenses and restrictions
460 contained in BCP 78, and except as set forth therein, the authors
461 retain all their rights.
463 This document and the information contained herein are provided on an
464 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
465 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
466 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
467 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
468 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
469 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
471 Intellectual Property
473 The IETF takes no position regarding the validity or scope of any
474 Intellectual Property Rights or other rights that might be claimed to
475 pertain to the implementation or use of the technology described in
476 this document or the extent to which any license under such rights
477 might or might not be available; nor does it represent that it has
478 made any independent effort to identify any such rights. Information
479 on the procedures with respect to rights in RFC documents can be
480 found in BCP 78 and BCP 79.
482 Copies of IPR disclosures made to the IETF Secretariat and any
483 assurances of licenses to be made available, or the result of an
484 attempt made to obtain a general license or permission for the use of
485 such proprietary rights by implementers or users of this
486 specification can be obtained from the IETF on-line IPR repository at
487 http://www.ietf.org/ipr.
489 The IETF invites any interested party to bring to its attention any
490 copyrights, patents or patent applications, or other proprietary
491 rights that may cover technology that may be required to implement
492 this standard. Please address the information to the IETF at
493 ietf-ipr@ietf.org.
495 Acknowledgement
497 Funding for the RFC Editor function is provided by the IETF
498 Administrative Support Activity (IASA).
506 Zeilenga Standards Track [Page 9]