Anonymous SASL Mechanism
obsoleted by
- rfc-4505 — Anonymous Simple Authentication and Security Layer (SASL) Mechanism
Extracted elements (16)
Anonymous trace information should take one of three forms: an Internet email address, an opaque string without '@', or nothing. This provides flexibility while allowing administrators to identify the source of access without mandating disclosure of user identity.
For privacy reasons, an Internet email address should only be used as trace information with permission from the user. This acknowledges that exposing a real email address in anonymous access contexts can violate user privacy.
The example uses the IMAP profile of SASL where base64 encoding of challenges/responses and the '+ ' prefix are part of the IMAP4 profile, not SASL itself. Newer SASL profiles include the client message with the AUTHENTICATE command, eliminating the extra round trip.
Protocols which offer restricted data access should not allow anonymous data access without an explicit login step.
The local-part of an email address used as trace information MUST either be entirely enclosed in quotes or entirely unquoted.
A client which sends the user's correct email address as trace information without explicit permission may violate that user's privacy, particularly for access to sensitive subjects. Clients should not send the email address without explicit user permission and should offer the option of supplying no trace token.
The SASL mechanism name for anonymous access is 'ANONYMOUS'. It consists of a single message from the client to the server containing optional trace information.
Anonymous connections are susceptible to man-in-the-middle attacks that view or alter transferred data. Clients and servers are encouraged to support external integrity and encryption mechanisms.
Anonymous users running expensive operations (e.g., IMAP SEARCH BODY) could mount denial of service attacks. Servers should limit the number of anonymous users and reduce their priority or resource usage.
If anonymous users have both read and write access to the same area, the server can be used as an anonymous communication channel. Servers accepting anonymous submissions should implement the 'drop box' model forbidding anonymous read access to submission areas.
If anonymous users have write privileges, a denial of service attack is possible by filling up all available space. Anonymous write access should be disabled to prevent this.
Protocols that fail to require an explicit anonymous login step are more susceptible to break-ins. Unix servers may start as root and switch user IDs only after explicit login; without explicit anonymous login, protective measures like chroot cannot be applied and the data access machinery is exposed.
The ANONYMOUS mechanism should be disabled by default so that administrators must make an explicit decision to enable it, preventing unintentional anonymous access to services.
Trace information is not authenticated and can be falsified, potentially framing others for questionable access. Administrators tracing abuse must recognize that trace information may be forged.
Without an idle timeout for anonymous users combined with a limit on concurrent anonymous users, a denial of service attack is possible. Servers should implement an idle timeout for anonymous users.
The client message is defined by ABNF as: message = [email / token], where token = 1*255TCHAR and TCHAR = %x20-3F / %x41-7E (any printable US-ASCII except '@'). The email form follows addr-spec from RFC 822 with no free insertion of linear-white-space.