Anonymous SASL Mechanism
RFC 2245

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

Network Working Group                                          C. Newman
Request for Comments: 2245                                      Innosoft
Category: Standards Track                                  November 1997

                        Anonymous SASL Mechanism

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 (1997).  All Rights Reserved.

Abstract

   It is common practice on the Internet 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
   optional trace information, such as an email address, as the
   password.  As plaintext login commands are not permitted in new IETF
   protocols, a new way to provide anonymous login is needed within the
   context of the SASL [SASL] framework.

1. Conventions Used in this Document

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in "Key words for
   use in RFCs to Indicate Requirement Levels" [KEYWORDS].

2. Anonymous SASL mechanism

   The mechanism name associated with anonymous access is "ANONYMOUS".
   The mechanism consists of a single message from the client to the
   server.  The client sends optional trace information in the form of a
   human readable string.  The trace information should take one of
   three forms: an Internet email address, an opaque string which does
   not contain the '@' character and can be interpreted by the system
   administrator of the client's domain, or nothing.  For privacy
   reasons, an Internet email address should only be used with
   permission from the user.

Newman                      Standards Track                     [Page 1]
RFC 2245                Anonymous SASL Mechanism           November 1997

   A server which permits anonymous access will announce support for the
   ANONYMOUS mechanism, and allow anyone to log in using that mechanism,
   usually with restricted access.

   The formal grammar for the client message using Augmented BNF [ABNF]
   follows.

   message         = [email / token]

   TCHAR           = %x20-3F / %x41-7E
                     ;; any printable US-ASCII character except '@'

   email           = addr-spec
                     ;; as defined in [IMAIL], except with no free
                     ;; insertion of linear-white-space, and the
                     ;; local-part MUST either be entirely enclosed in
                     ;; quotes or entirely unquoted

   token           = 1*255TCHAR

3. Example

   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 [IMAP4] 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.  Newer profiles of SASL will include the client message
   with the AUTHENTICATE command itself so the extra round trip below
   (the server response with an empty "+ ") can be eliminated.

   In this example, the user's opaque identification token is "sirhc".

        S: * OK IMAP4 server ready
        C: A001 CAPABILITY
        S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=ANONYMOUS
        S: A001 OK done
        C: A002 AUTHENTICATE ANONYMOUS
        S: +
        C: c2lyaGM=
        S: A003 OK Welcome, trace information has been logged.

Newman                      Standards Track                     [Page 2]
RFC 2245                Anonymous SASL Mechanism           November 1997

4. Security Considerations

   The anonymous mechanism grants access to information by anyone.  For
   this reason it should be disabled by default so 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 anonymously
   exchange information.  Servers which 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