doc/rfc2245.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          C. Newman
   8 Request for Comments: 2245                                      Innosoft
   9 Category: Standards Track                                  November 1997
  10
  11
  12                         Anonymous SASL Mechanism
  13
  14 Status 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
  22 Copyright Notice
  23
  24    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  25
  26 Abstract
  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
  36 1. 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
  42 2. 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
  58 Newman                      Standards Track                     [Page 1]
  59 \f
  60 RFC 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
  83 3. 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
 114 Newman                      Standards Track                     [Page 2]
 115 \f
 116 RFC 2245                Anonymous SASL Mechanism           November 1997
 117
 118
 119 4. 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
 170 Newman                      Standards Track                     [Page 3]
 171 \f
 172 RFC 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
 185 5. 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
 202 6. 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
 226 Newman                      Standards Track                     [Page 4]
 227 \f
 228 RFC 2245                Anonymous SASL Mechanism           November 1997
 229
 230
 231 7.  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
 282 Newman                      Standards Track                     [Page 5]
 283 \f