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