Anonymous Simple Authentication and Security Layer (SASL) Mechanism
obsoletes
- rfc-2245 — Anonymous SASL Mechanism
Extracted elements (18)
Plain-text password mechanisms using 'anonymous' as username are not permitted in new IETF protocols, necessitating a SASL-based anonymous mechanism. The ANONYMOUS mechanism provides anonymous login without requiring identity disclosure within the SASL framework.
Trace information has no semantical value and should take one of two forms: an Internet email address, or an opaque string without '@' interpretable by the client domain's administrator. This design allows optional accountability without requiring identity disclosure.
RFC 2245 restricted trace information to US-ASCII. RFC 4505 extends this to UTF-8-encoded Unicode characters with a stringprep profile, while retaining the 255-character limit. Encoded length per character now ranges from 1 to 4 octets.
For privacy reasons, an Internet email address or other information identifying the user should only be used with permission from the user.
The ANONYMOUS mechanism does not provide a security layer.
The 'trace' profile requires bidirectional character checking per Section 6 of [StringPrep].
Clients should not send the user's email address as trace information without explicit user permission, and should offer the option of supplying no trace information. Anyone accessing anonymous archives on sensitive subjects has strong privacy needs.
The ANONYMOUS SASL mechanism consists of a single message from the client to the server. The client may include optional trace information as a UTF-8-encoded Unicode string prepared according to the 'trace' stringprep profile.
The 'trace' stringprep profile is defined for use with the SASL ANONYMOUS mechanism. It uses the Unicode 3.2 character repertoire, requires no mapping or normalization, and prohibits characters from StringPrep tables C.2.1, C.2.2, C.3, C.4, C.5, C.6, C.8, and C.9.
The SASL Mechanism registry entry for the ANONYMOUS mechanism has been updated to reference RFC 4505 as the technical specification, with intended usage COMMON and IESG as author/change controller.
The StringPrep profile 'trace', first defined in RFC 4505, has been registered with IANA.
Anonymous connections are susceptible to man-in-the-middle attacks that view or alter transferred data. Clients and servers are encouraged to support external data security services.
If anonymous users have both read and write access to the same area, the server can be used as an anonymous communication channel. The 'drop box' model should be implemented to forbid anonymous read access to areas accepting anonymous submissions.
Protocols that do not require explicit anonymous login are more susceptible to break-ins. Protocols offering restricted data access should not allow anonymous access without an explicit login step, enabling protective measures such as Unix chroot.
Servers are encouraged to reduce priority or limit resource usage for anonymous users to prevent denial-of-service attacks via expensive operations (e.g., IMAP SEARCH BODY). Limits on number of anonymous users can themselves enable DoS and should be used with caution.
The ANONYMOUS mechanism grants access to anyone and should be disabled by default so administrators can make an explicit decision to enable it. If anonymous users have write privileges, denial-of-service attacks are possible by exhausting storage.
Trace information is not authenticated and can be falsified, potentially framing innocent parties for access to questionable information. Administrators investigating abuse must account for this.
The client message is defined as an optional email address or token. A token is 1 to 255 UTF-8-encoded Unicode characters (excluding '@'), with encoded length up to 1020 octets (since each character may use 1-4 octets).