doc/specification/draft-newman-sasl-anon-00.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          C. Newman
   8 Internet Draft: Anonymous SASL Mechanism                        Innosoft
   9 Document: draft-newman-sasl-anon-00.txt                        June 1997
  10                                                    Expires in six months
  11
  12
  13                         Anonymous SASL Mechanism
  14
  15
  16 Status of this memo
  17
  18      This document is an Internet-Draft.  Internet-Drafts are working
  19      documents of the Internet Engineering Task Force (IETF), its areas,
  20      and its working groups.  Note that other groups may also distribute
  21      working documents as Internet-Drafts.
  22
  23      Internet-Drafts are draft documents valid for a maximum of six
  24      months and may be updated, replaced, or obsoleted by other
  25      documents at any time.  It is inappropriate to use Internet-Drafts
  26      as reference material or to cite them other than as "work in
  27      progress."
  28
  29      To view the entire list of current Internet-Drafts, please check
  30      the "1id-abstracts.txt" listing contained in the Internet-Drafts
  31      Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
  32      (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  33      Coast), or ftp.isi.edu (US West Coast).
  34
  35
  36 Abstract
  37
  38      It is common practice on the Internet to permit anonymous access to
  39      various services.  Traditionally, this has been done within the
  40      context of a plain text password mechanism using "anonymous" as the
  41      user name and trace information, such as an email address, as the
  42      password.  As SASL [SASL] provides a framework for authentication
  43      mechanisms, a formalized anonymous mechanism is simple to add.
  44
  45
  46 1. Conventions Used in this Document
  47
  48      The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
  49      in this document are to be interpreted as defined in "Key words for
  50      use in RFCs to Indicate Requirement Levels" [KEYWORDS].
  51
  52
  53
  54
  55
  56
  57
  58 Newman                                                          [Page 1]
  59 \f
  60 Internet Draft          Anonymous SASL Mechanism               June 1997
  61
  62
  63 2. Anonymous SASL mechanism
  64
  65      The mechanism name associated with anonymous access is "ANONYMOUS".
  66
  67      The mechanism consists of a single message from the client to the
  68      server.  The client sends optional trace information in the form of
  69      a human readable string.  The trace information should take one of
  70      three forms: an Internet email address, an opaque string which does
  71      not contain the '@' character and can be interpreted by the system
  72      administrator of the client's domain, or nothing.  For privacy
  73      reasons, an Internet email address should only be used with
  74      permission from the user.
  75
  76      A server which permits anonymous access will announce support for
  77      the ANONYMOUS mechanism, and allow anyone to log in using that
  78      mechanism, usually with restricted access.
  79
  80      The formal grammar for the client message using Augmented BNF
  81      [ABNF] follows.
  82
  83      message         = [email / token]
  84
  85      TCHAR           = %x20..3F / %x41..7E
  86                        ;; any printable US-ASCII character except '@'
  87
  88      email           = addr-spec
  89                        ;; as defined in RFC 822, except with no free
  90                        ;; insertion of linear-white-space, and the
  91                        ;; local-part MUST either be entirely enclosed in
  92                        ;; quotes or entirely unquoted
  93
  94      token           = 1*255TCHAR
  95
  96 3. Example
  97
  98      Here is a sample anonymous login between an IMAP client and server.
  99      In this example, "C:" and "S:" indicate lines sent by the client
 100      and server respectively.  If such lines are wrapped without a new
 101      "C:" or "S:" label, then the wrapping is for editorial clarity and
 102      is not part of the command.
 103
 104      Note that this example uses the IMAP profile [IMAP4] of SASL.  The
 105      base64 encoding of challenges and responses, as well as the "+ "
 106      preceding the responses are part of the IMAP4 profile, not part of
 107      SASL itself.  Newer profiles of SASL will include the client
 108      message with the AUTHENTICATE command itself so the extra round
 109      trip below (the server response with an empty "+ ") can be
 110      eliminated.
 111
 112
 113
 114 Newman                                                          [Page 2]
 115 \f
 116 Internet Draft          Anonymous SASL Mechanism               June 1997
 117
 118
 119      In this example, the user's opaque identification token is "sirhc".
 120
 121         S: * OK IMAP4 server ready
 122         C: A001 CAPABILITY
 123         S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=ANONYMOUS
 124         S: A001 OK done
 125         C: A002 AUTHENTICATE ANONYMOUS
 126         S: +
 127         C: c2lyaGM=
 128         S: A003 OK Welcome, trace information "sirhc" has been logged.
 129
 130 4. Security Considerations
 131
 132      If the anonymous user has any write privileges, a denial of service
 133      attack is possible by filling up all available space.  This can be
 134      prevented by disabling all write access by anonymous users.
 135
 136      If anonymous users have read and write access to the same area, the
 137      server can be used as a communication mechanism to anonymously
 138      exchange illegal information.  Servers which accept anonymous
 139      submissions should implement the common "drop box" model which
 140      forbids anonymous read access to the area where anonymous
 141      submissions are accepted.
 142
 143      If the anonymous user can run many expensive operations (e.g. an
 144      IMAP SEARCH BODY command), this could enable a denial of service
 145      attack.  Servers are encouraged to limit the number of anonymous
 146      users and reduce their priority or limit their resource usage.
 147
 148      If there is no idle timeout for the anonymous user and there is a
 149      limit on the number of anonymous users, a denial of service attack
 150      is enabled.  Servers should implement an idle timeout for anonymous
 151      users.
 152
 153      The trace information is not authenticated so it can be falsified.
 154      This can be used as an attempt to get someone else in trouble for
 155      access to questionable information.  Administrators trying to trace
 156      abuse need to realize this information may be falsified.  Servers
 157      which need reliable trace information should not offer the
 158      ANONYMOUS mechanism.
 159
 160      A client which uses the user's correct email address as trace
 161      information without explicit permission may violate that user's
 162      privacy.  Information about who accesses an anonymous archive on a
 163      sensitive subject (e.g. sexual abuse) has strong privacy needs.
 164      Clients should not send the email address without explicit
 165
 166
 167
 168
 169
 170 Newman                                                          [Page 3]
 171 \f
 172 Internet Draft          Anonymous SASL Mechanism               June 1997
 173
 174
 175      permission of the user and should offer the option of supplying no
 176      trace token -- thus only exposing the source IP address and time.
 177      Anonymous proxy servers could enhance this privacy, but would have
 178      to consider the resulting potential denial of service attacks.
 179
 180      Anonymous connections are susceptible to man in the middle attacks
 181      which alter the data transferred.  Clients and servers are
 182      encouraged to support external integrity and encryption mechanisms.
 183
 184      Protocols which fail to require an explicit anonymous login are
 185      more susceptible to break-ins given certain common implementation
 186      techniques.  Specifically, Unix servers which offer user login may
 187      initially start up as root and switch to the appropriate user id
 188      after an explicit login command.  Normally such servers refuse all
 189      data access commands prior to explicit login and may enter a
 190      restricted security environment (e.g. the Unix chroot function) for
 191      anonymous users.  If anonymous access is not explicitly requested,
 192      the entire data access machinery is exposed to external security
 193      attacks without the chance for explicit protective measures.
 194      Protocols which offer restricted data access should not allow
 195      anonymous data access without an explicit login step.
 196
 197 5. References
 198
 199      [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications:
 200      ABNF", Work in progress: draft-ietf-drums-abnf-xx.txt
 201
 202      [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
 203      4rev1", RFC 2060, University of Washington, December 1996.
 204
 205          <ftp://ds.internic.net/rfc/rfc2060.txt>
 206
 207      [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
 208      Requirement Levels", RFC 2119, Harvard University, March 1997.
 209
 210          <ftp://ds.internic.net/rfc/rfc2119.txt>
 211
 212      [SASL] Myers, "Simple Authentication and Security Layer (SASL)",
 213      work in progress.
 214
 215 6. Author's Address
 216
 217      Chris Newman
 218      Innosoft International, Inc.
 219      1050 Lakes Drive
 220      West Covina, CA 91790 USA
 221
 222      Email: chris.newman@innosoft.com
 223
 224
 225
 226 Newman                                                          [Page 4]
 227 \f
 228 Internet Draft          Anonymous SASL Mechanism               June 1997
 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 Newman                                                          [Page 5]
 283 \f
 284