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