1 2 3 4 5 6 7Network Working Group K. Zeilenga, Ed. 8Request for Comments: 4505 OpenLDAP Foundation 9Obsoletes: 2245 June 2006 10Category: Standards Track 11 12 13 Anonymous Simple Authentication and Security Layer (SASL) Mechanism 14 15Status of This Memo 16 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. 22 23Copyright Notice 24 25 Copyright (C) The Internet Society (2006). 26 27Abstract 28 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. 37 381. Introduction 39 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". 43 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. 50 51 This mechanism does not provide a security layer. 52 53 This document replaces RFC 2245. Changes since RFC 2245 are detailed 54 in Appendix A. 55 56 57 58Zeilenga Standards Track [Page 1] 59 60RFC 4505 Anonymous SASL Mechanism June 2006 61 62 632. The Anonymous Mechanism 64 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. 76 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. 80 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. 84 85 message = [ email / token ] 86 ;; to be prepared in accordance with Section 3 87 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 95 96 TCHAR = UTF1 / UTF2 / UTF3 / UTF4 97 ;; any UTF-8 encoded Unicode character 98 ;; except '@' (U+0040) 99 100 email = addr-spec 101 ;; as defined in [IMAIL] 102 103 token = 1*255TCHAR 104 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. 109 110 111 112 113 114Zeilenga Standards Track [Page 2] 115 116RFC 4505 Anonymous SASL Mechanism June 2006 117 118 1193. The "trace" Profile of "Stringprep" 120 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. 125 126 The character repertoire of this profile is Unicode 3.2 [Unicode]. 127 128 No mapping is required by this profile. 129 130 No Unicode normalization is required by this profile. 131 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. 135 136 Characters from the following tables of [StringPrep] are prohibited: 137 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) 146 147 No additional characters are prohibited. 148 149 This profile requires bidirectional character checking per Section 6 150 of [StringPrep]. 151 1524. Example 153 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. 159 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 "+ "). 166 167 168 169 170Zeilenga Standards Track [Page 3] 171 172RFC 4505 Anonymous SASL Mechanism June 2006 173 174 175 In this example, the trace information is "sirhc". 176 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. 185 1865. Security Considerations 187 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. 191 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. 195 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. 201 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. 206 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. 210 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. 215 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. 223 224 225 226Zeilenga Standards Track [Page 4] 227 228RFC 4505 Anonymous SASL Mechanism June 2006 229 230 231 Anonymous proxy servers could enhance this privacy but would have to 232 consider the resulting potential denial-of-service attacks. 233 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. 237 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. 250 251 General [SASL] security considerations apply to this mechanism. 252 253 [StringPrep] security considerations and [Unicode] security 254 considerations discussed in [StringPrep] apply to this mechanism. 255 [UTF-8] security considerations also apply. 256 2576. IANA Considerations 258 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. 262 263 To: iana@iana.org 264 Subject: Updated Registration of SASL mechanism ANONYMOUS 265 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 275 276 277 278 279 280 281 282Zeilenga Standards Track [Page 5] 283 284RFC 4505 Anonymous SASL Mechanism June 2006 285 286 287 The [StringPrep] profile "trace", first defined in this RFC, has been 288 registered: 289 290 To: iana@iana.org 291 Subject: Initial Registration of Stringprep "trace" profile 292 293 Stringprep profile: trace 294 Published specification: RFC 4505 295 Person & email address to contact for further information: 296 Kurt Zeilenga <kurt@openldap.org> 297 2987. Acknowledgement 299 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. 303 304 This document is a product of the IETF SASL WG. 305 3068. Normative References 307 308 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 309 Specifications: ABNF", RFC 4234, October 2005. 310 311 [IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April 312 2001. 313 314 [SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 315 Authentication and Security Layer (SASL)", RFC 4422, 316 June 2006. 317 318 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of 319 Internationalized Strings ('stringprep')", RFC 3454, 320 December 2002. 321 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/). 329 330 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 331 10646", RFC 3629 (also STD 63), November 2003. 332 333 334 335 336 337 338Zeilenga Standards Track [Page 6] 339 340RFC 4505 Anonymous SASL Mechanism June 2006 341 342 3439. Informative References 344 345 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 346 4rev1", RFC 3501, March 2003. 347 348 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 349 MECHANISMS", <http://www.iana.org/assignments/sasl- 350 mechanisms>. 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 394Zeilenga Standards Track [Page 7] 395 396RFC 4505 Anonymous SASL Mechanism June 2006 397 398 399Appendix A. Changes since RFC 2245 400 401 This appendix is non-normative. 402 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. 411 412 Additionally, a number of editorial changes were made. 413 414Editor's Address 415 416 Kurt D. Zeilenga 417 OpenLDAP Foundation 418 419 EMail: Kurt@OpenLDAP.org 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 450Zeilenga Standards Track [Page 8] 451 452RFC 4505 Anonymous SASL Mechanism June 2006 453 454 455Full Copyright Statement 456 457 Copyright (C) The Internet Society (2006). 458 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. 462 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. 470 471Intellectual Property 472 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. 481 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. 488 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. 494 495Acknowledgement 496 497 Funding for the RFC Editor function is provided by the IETF 498 Administrative Support Activity (IASA). 499 500 501 502 503 504 505 506Zeilenga Standards Track [Page 9] 507 508