RFC 4505

Anonymous Simple Authentication and Security Layer (SASL) Mechanism

📅 published June 2006, from ietf

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

okay bestie, let's get into this one 💖 here's the title block:

  • Network Working Group 🌸
  • Request for Comments: 4505
  • Editor: K. Zeilenga, Ed., from the OpenLDAP Foundation 🦋
  • Date: June 2006 📅
  • Category: Standards Track 👑
  • Obsoletes: RFC 2245 (so this one officially replaces 2245 💅)
  • Updates: nothing listed in the header

Status of This Memo 🌸

so this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 for the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 and distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2006) 🧚

Abstract ✨

it's super common on the Internet to let people in anonymously 🙈 traditionally that was done with a plain-text password mechanism where you used "anonymous" as the user name and optional trace info, like an email address, as the password. but plain-text login commands aren't allowed in new IETF protocols anymore 💀 so we need a new way to do anonymous login inside the Simple Authentication and Security Layer (SASL) framework 🔥

1. Introduction 🦋

this document defines an anonymous mechanism for the Simple Authentication and Security Layer ([SASL]) framework 💖 the name for this mechanism is "ANONYMOUS" ✨

this is the big difference: most SASL mechanisms exist to authenticate and identify the user to a server 🪪 this one is the opposite. its whole purpose is letting the user get access to services or resources without having to establish or disclose their identity to the server 🫣 so it's an anonymous login method, period 💅

this mechanism does not provide a security layer 🙅‍♀️

this document replaces RFC 2245 🔄 changes since RFC 2245 are detailed in Appendix A 📝

2. The Anonymous Mechanism 🍓

the mechanism is just one single message from the client to the server 📨 the client may include trace information in that message. the trace info is a string of [UTF-8]-encoded [Unicode] characters, prepared according to [StringPrep] and the "trace" stringprep profile defined in Section 3 of this document 🧁

the trace info has no semantic value 🤷‍♀️ it 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 info identifying the user should only be used with the user's permission 🔐 bestie, this part matters a lot

a server that allows anonymous access will announce support for the ANONYMOUS mechanism and let anyone log in with it, usually with restricted access 🚪✨

here's a formal grammar for the client message using Augmented BNF [ABNF]. it's provided as a tool for understanding this spec 🧠

   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. since encoding a character uses a sequence of 1 to 4 octets, a token may be as long as 1020 octets 🧮

3. The "trace" Profile of "Stringprep" 💅

this section defines the "trace" profile of [StringPrep] ✨ it's designed for use with the SASL ANONYMOUS mechanism. specifically, the client is supposed to prepare the <message> production according to 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 either 🙅‍♀️

the list of unassigned code points for this profile is the one provided in Appendix A of [StringPrep]. unassigned code points are not prohibited 🫧

these characters from the following tables of [StringPrep] are prohibited 🚫:

  • C.2.1 (ASCII control characters)
  • C.2.2 (Non-ASCII control characters)
  • C.3 (Private use characters)
  • C.4 (Non-character code points)
  • C.5 (Surrogate codes)
  • C.6 (Inappropriate for plain text)
  • C.8 (Change display properties are deprecated)
  • C.9 (Tagging characters)

no additional characters are prohibited 🙌

this profile requires bidirectional character checking per Section 6 of [StringPrep] 🔄🦋

8. Normative References 📚

okay so these are the docs this spec basically leans on 🫶 you need them to read the rest properly, no cap

  • [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
  • [IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
  • [SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
  • [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ('stringprep')", RFC 3454, December 2002.
  • [Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
  • [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629 (also STD 63), November 2003.

9. Informative References 🌸

these ones are more like bonus reading, the spec doesn't need them to work but they're giving helpful context 🧚

Appendix A. Changes since RFC 2245 🦋

this appendix is non-normative, so it's just the glow-up recap ✨

okay so RFC 2245 let the client send optional trace info as a human readable string 💖 but it only allowed US-ASCII, which is lowkey a problem because the internet is literally international 🌍 so this doc switches to a string made of UTF-8 encoded Unicode characters 🫶 there's a "stringprep" profile that spells out exactly which Unicode characters are allowed 💅 the string is still capped at 255 characters, but each character can now be anywhere from 1 to 4 octets long once encoded 🔥

and yeah there were also a bunch of editorial cleanups, nothing too dramatic 🎀

Editor's Address 💌

Kurt D. Zeilenga OpenLDAP Foundation

EMail: Kurt@OpenLDAP.org

Copyright (C) The Internet Society (2006).

this document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

this document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭

Intellectual Property 🔥

the IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. please address the information to the IETF at ietf-ipr@ietf.org. 🫶

Acknowledgement 🌈

funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 💜

and that's the whole spec, bestie 🎀✨ the anonymous mechanism is secretly super elegant once you see how the trace string works 👑

📦 where this page comes from