1
2
3
4
5
6
7Network Working Group                                          C. Newman
8Request for Comments: 2245                                      Innosoft
9Category: Standards Track                                  November 1997
10
11
12                        Anonymous SASL Mechanism
13
14Status of this Memo
15
16   This document specifies an Internet standards track protocol for the
17   Internet community, and requests discussion and suggestions for
18   improvements.  Please refer to the current edition of the "Internet
19   Official Protocol Standards" (STD 1) for the standardization state
20   and status of this protocol.  Distribution of this memo is unlimited.
21
22Copyright Notice
23
24   Copyright (C) The Internet Society (1997).  All Rights Reserved.
25
26Abstract
27
28   It is common practice on the Internet to permit anonymous access to
29   various services.  Traditionally, this has been done with a plain
30   text password mechanism using "anonymous" as the user name and
31   optional trace information, such as an email address, as the
32   password.  As plaintext login commands are not permitted in new IETF
33   protocols, a new way to provide anonymous login is needed within the
34   context of the SASL [SASL] framework.
35
361. Conventions Used in this Document
37
38   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
39   in this document are to be interpreted as defined in "Key words for
40   use in RFCs to Indicate Requirement Levels" [KEYWORDS].
41
422. Anonymous SASL mechanism
43
44   The mechanism name associated with anonymous access is "ANONYMOUS".
45   The mechanism consists of a single message from the client to the
46   server.  The client sends optional trace information in the form of a
47   human readable string.  The trace information should take one of
48   three forms: an Internet email address, an opaque string which does
49   not contain the '@' character and can be interpreted by the system
50   administrator of the client's domain, or nothing.  For privacy
51   reasons, an Internet email address should only be used with
52   permission from the user.
53
54
55
56
57
58Newman                      Standards Track                     [Page 1]
59
60RFC 2245                Anonymous SASL Mechanism           November 1997
61
62
63   A server which permits anonymous access will announce support for the
64   ANONYMOUS mechanism, and allow anyone to log in using that mechanism,
65   usually with restricted access.
66
67   The formal grammar for the client message using Augmented BNF [ABNF]
68   follows.
69
70   message         = [email / token]
71
72   TCHAR           = %x20-3F / %x41-7E
73                     ;; any printable US-ASCII character except '@'
74
75   email           = addr-spec
76                     ;; as defined in [IMAIL], except with no free
77                     ;; insertion of linear-white-space, and the
78                     ;; local-part MUST either be entirely enclosed in
79                     ;; quotes or entirely unquoted
80
81   token           = 1*255TCHAR
82
833. Example
84
85
86   Here is a sample anonymous login between an IMAP client and server.
87   In this example, "C:" and "S:" indicate lines sent by the client and
88   server respectively.  If such lines are wrapped without a new "C:" or
89   "S:" label, then the wrapping is for editorial clarity and is not
90   part of the command.
91
92   Note that this example uses the IMAP profile [IMAP4] of SASL.  The
93   base64 encoding of challenges and responses, as well as the "+ "
94   preceding the responses are part of the IMAP4 profile, not part of
95   SASL itself.  Newer profiles of SASL will include the client message
96   with the AUTHENTICATE command itself so the extra round trip below
97   (the server response with an empty "+ ") can be eliminated.
98
99   In this example, the user's opaque identification token is "sirhc".
100
101        S: * OK IMAP4 server ready
102        C: A001 CAPABILITY
103        S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=ANONYMOUS
104        S: A001 OK done
105        C: A002 AUTHENTICATE ANONYMOUS
106        S: +
107        C: c2lyaGM=
108        S: A003 OK Welcome, trace information has been logged.
109
110
111
112
113
114Newman                      Standards Track                     [Page 2]
115
116RFC 2245                Anonymous SASL Mechanism           November 1997
117
118
1194. Security Considerations
120
121   The anonymous mechanism grants access to information by anyone.  For
122   this reason it should be disabled by default so the administrator can
123   make an explicit decision to enable it.
124
125   If the anonymous user has any write privileges, a denial of service
126   attack is possible by filling up all available space.  This can be
127   prevented by disabling all write access by anonymous users.
128
129   If anonymous users have read and write access to the same area, the
130   server can be used as a communication mechanism to anonymously
131   exchange information.  Servers which accept anonymous submissions
132   should implement the common "drop box" model which forbids anonymous
133   read access to the area where anonymous submissions are accepted.
134
135   If the anonymous user can run many expensive operations (e.g., an
136   IMAP SEARCH BODY command), this could enable a denial of service
137   attack.  Servers are encouraged to limit the number of anonymous
138   users and reduce their priority or limit their resource usage.
139
140   If there is no idle timeout for the anonymous user and there is a
141   limit on the number of anonymous users, a denial of service attack is
142   enabled.  Servers should implement an idle timeout for anonymous
143   users.
144
145   The trace information is not authenticated so it can be falsified.
146   This can be used as an attempt to get someone else in trouble for
147   access to questionable information.  Administrators trying to trace
148   abuse need to realize this information may be falsified.
149
150   A client which uses the user's correct email address as trace
151   information without explicit permission may violate that user's
152   privacy.  Information about who accesses an anonymous archive on a
153   sensitive subject (e.g., sexual abuse) has strong privacy needs.
154   Clients should not send the email address without explicit permission
155   of the user and should offer the option of supplying no trace token
156   -- thus only exposing the source IP address and time.  Anonymous
157   proxy servers could enhance this privacy, but would have to consider
158   the resulting potential denial of service attacks.
159
160   Anonymous connections are susceptible to man in the middle attacks
161   which view or alter the data transferred.  Clients and servers are
162   encouraged to support external integrity and encryption mechanisms.
163
164   Protocols which fail to require an explicit anonymous login are more
165   susceptible to break-ins given certain common implementation
166   techniques.  Specifically, Unix servers which offer user login may
167
168
169
170Newman                      Standards Track                     [Page 3]
171
172RFC 2245                Anonymous SASL Mechanism           November 1997
173
174
175   initially start up as root and switch to the appropriate user id
176   after an explicit login command.  Normally such servers refuse all
177   data access commands prior to explicit login and may enter a
178   restricted security environment (e.g., the Unix chroot function) for
179   anonymous users.  If anonymous access is not explicitly requested,
180   the entire data access machinery is exposed to external security
181   attacks without the chance for explicit protective measures.
182   Protocols which offer restricted data access should not allow
183   anonymous data access without an explicit login step.
184
1855. References
186
187   [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
188   Specifications: ABNF", RFC 2234, November 1997.
189
190   [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text
191   Messages", STD 11, RFC 822, August 1982.
192
193   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
194   4rev1", RFC 2060, December 1996.
195
196   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
197   Requirement Levels", RFC 2119, March 1997.
198
199   [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",
200   RFC 2222, October 1997.
201
2026. Author's Address
203
204   Chris Newman
205   Innosoft International, Inc.
206   1050 Lakes Drive
207   West Covina, CA 91790 USA
208
209   Email: chris.newman@innosoft.com
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226Newman                      Standards Track                     [Page 4]
227
228RFC 2245                Anonymous SASL Mechanism           November 1997
229
230
2317.  Full Copyright Statement
232
233   Copyright (C) The Internet Society (1997).  All Rights Reserved.
234
235   This document and translations of it may be copied and furnished to
236   others, and derivative works that comment on or otherwise explain it
237   or assist in its implementation may be prepared, copied, published
238   and distributed, in whole or in part, without restriction of any
239   kind, provided that the above copyright notice and this paragraph are
240   included on all such copies and derivative works.  However, this
241   document itself may not be modified in any way, such as by removing
242   the copyright notice or references to the Internet Society or other
243   Internet organizations, except as needed for the purpose of
244   developing Internet standards in which case the procedures for
245   copyrights defined in the Internet Standards process must be
246   followed, or as required to translate it into languages other than
247   English.
248
249   The limited permissions granted above are perpetual and will not be
250   revoked by the Internet Society or its successors or assigns.
251
252   This document and the information contained herein is provided on an
253   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
254   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
255   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
256   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
257   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282Newman                      Standards Track                     [Page 5]
283
284