Anonymous Simple Authentication and Security Layer (SASL) Mechanism
RFC 4505

Document Type RFC - Proposed Standard (June 2006; No errata)
Obsoletes RFC 2245
Author Kurt Zeilenga 
Last updated 2015-10-14
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 4505 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Sam Hartman
Send notices to (None)
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 Notice

   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)

1.  Introduction

   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 2006

2.  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 2006

3.  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].

   No mapping is required by this profile.

   No Unicode normalization is required by this profile.

   The list of unassigned code points for this profile is that provided
   in Appendix A of [StringPrep].  Unassigned code points are not

   Characters from the following tables of [StringPrep] are prohibited:
Show full document text