Network Working Group K. Zeilenga, Ed.
Request for Comments: 4505 OpenLDAP Foundation
Obsoletes: 2245 June 2006
Category: Standards Track
Anonymous Simple Authentication and Security Layer (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 (C) The Internet Society (2006).
On the Internet, it is common practice 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 using
optional trace information, such as an email address, as the
password. As plain-text login commands are not permitted in new IETF
protocols, a new way to provide anonymous login is needed within the
context of the Simple Authentication and Security Layer (SASL)
This document defines an anonymous mechanism for the Simple
Authentication and Security Layer ([SASL]) framework. The name
associated with this mechanism is "ANONYMOUS".
Unlike many other SASL mechanisms, whose purpose is to authenticate
and identify the user to a server, the purpose of this SASL mechanism
is to allow the user to gain access to services or resources without
requiring the user to establish or otherwise disclose their identity
to the server. That is, this mechanism provides an anonymous login
This mechanism does not provide a security layer.
This document replaces RFC 2245. Changes since RFC 2245 are detailed
in Appendix A.
Zeilenga Standards Track [Page 1]RFC 4505 Anonymous SASL Mechanism June 20062. The Anonymous Mechanism
The mechanism consists of a single message from the client to the
server. The client may include in this message trace information in
the form of a string of [UTF-8]-encoded [Unicode] characters prepared
in accordance with [StringPrep] and the "trace" stringprep profile
defined in Section 3 of this document. The trace information, which
has no semantical value, should take one of two forms: an Internet
email address, or an opaque string that does not contain the '@'
(U+0040) character and that can be interpreted by the system
administrator of the client's domain. For privacy reasons, an
Internet email address or other information identifying the user
should only be used with permission from the user.
A server that permits anonymous access will announce support for the
ANONYMOUS mechanism and allow anyone to log in using that mechanism,
usually with restricted access.
A formal grammar for the client message using Augmented BNF [ABNF] is
provided below as a tool for understanding this technical
message = [ email / token ]
;; to be prepared in accordance with Section 3
UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040)
UTF2 = %xC2-DF UTF0
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
%xF4 %x80-8F 2(UTF0)
UTF0 = %x80-BF
TCHAR = UTF1 / UTF2 / UTF3 / UTF4
;; any UTF-8 encoded Unicode character
;; except '@' (U+0040)
email = addr-spec
;; as defined in [IMAIL]
token = 1*255TCHAR
Note to implementors:
The <token> production is restricted to 255 UTF-8-encoded Unicode
characters. As the encoding of a characters uses a sequence of 1
to 4 octets, a token may be as long as 1020 octets.
Zeilenga Standards Track [Page 2]RFC 4505 Anonymous SASL Mechanism June 20063. The "trace" Profile of "Stringprep"
This section defines the "trace" profile of [StringPrep]. This
profile is designed for use with the SASL ANONYMOUS Mechanism.
Specifically, the client is to prepare the <message> production in
accordance with this profile.
The character repertoire of this profile is Unicode 3.2 [Unicode].