RFC 5034

The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism

📅 published July 2007, from ietf

RFC 5034: The POP3 SASL Authentication Mechanism 🎀

Title: The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism

Authors: R. Siemborski (Google, Inc.) and A. Menon-Sen (Oryx Mail Systems GmbH) 💌

Category: Standards Track ✨

Date: July 2007 📅

Obsoletes: RFC 1734 🙈

Updates: RFC 2449 🔥

Network Working Group 🌸 Request for Comments: 5034

Status of This Memo 📜

Okay so this one's a standards track protocol for the Internet community 🌈, and the authors are literally asking everyone to send in discussion and suggestions for improvements 💖. For the official standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🧐. And the good news: distribution of this memo is unlimited 🦋.

Copyright (C) The IETF Trust (2007). 💜

Abstract ✨

Okay bestie, this document defines a profile of the Simple Authentication and Security Layer (SASL) for the Post Office Protocol (POP3) 📬. It lets a POP3 client name an authentication mechanism to the server, run the authentication protocol exchange, and optionally negotiate a security layer for the rest of the session 🔐. Iconic.

The goal here is to gather everything about POP3 AUTH into one single document 🧚. So this document obsoletes and replaces RFC 1734, and it updates the info in Section 6.3 of RFC 2449 💅.

1. Introduction 🌷

Okay so the POP3 AUTH command (see [RFC1939]) (see [RFC1734]) had a few problems in its spec, ngl 😭. The first one: it was super similar to a SASL framework defined by [RFC4422], but it came out before the initial SASL spec even existed 💀. So it was missing some key pieces, like a way to list the available authentication mechanisms 🙈.

Then [RFC2449] tried to fix that by adding the CAPA command and allowing an initial client response with the AUTH command 🎀. Still, the spec stayed unclear about how that initial client response was supposed to be handled 🫠.

Put together, making a full POP3 AUTH implementation means understanding material from at least five different documents, and [RFC3206] adds extra response codes that are useful during authentication 📚. Not it, honestly.

So this document combines the info from [RFC1734] and [RFC2449] to make things way simpler 💖. It also clarifies and updates the older specs wherever that makes sense 🦋.

2. Conventions Used in This Document 🧁

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These are the capital-letter BCP 14 words, so pay attention to them 👑.

In examples, "C:" and "S:" mark lines sent by the client and the server, respectively 🫶.

Formal syntax is defined by [RFC4234] ✨.

3. The SASL Capability 🌈

Bestie, this section supersedes the definition of the SASL Capability in section 6.3 of [RFC2449] 💅. Here's the official capability block:

CAPA tag:
   SASL

Arguments:
   Supported SASL Mechanisms

Added commands:
   AUTH

Standard commands affected:
   None

Announced states / possible differences:
   both / no

Commands valid in states:
   AUTHORIZATION

Specification reference:
   This document and [RFC4422]

Discussion:

The SASL capability lets you use the AUTH command (as defined in Section 4 of this document) to kick off a SASL negotiation (as defined in [RFC4422]) 🚀. The argument to the SASL capability is a space-separated list of SASL mechanisms that the server supports 🧚.

If a server either does not support the CAPA command or does not advertise the SASL capability, clients SHOULD NOT attempt the AUTH command 🙅‍♀️. If a client does attempt the AUTH command in that situation anyway, it MUST NOT supply the client initial response parameter (this is for backwards compatibility with [RFC1734]) 💀.

Heads up: the list of available mechanisms MAY change after a successful STLS command (see [RFC2595]) 🦋. But, as [RFC2449] requires, implementations MUST keep including the SASL capability even after a successful AUTH command has finished (even though no further AUTH commands may be issued) 🔥.

Here's an example, iykyk 🎀:

S: +OK pop.example.com BlurdyBlurp POP3 server ready
C: CAPA
S: +OK List of capabilities follows
S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
S: STLS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .

Okay, that's the first chunk of the tea ☕🌸. Part 2 is coming next, so don't go anywhere, bestie 🦋💖

4. The AUTH Command ✨

okay bestie, this is the big one 💅 the AUTH command is how the client kicks off a SASL login, and the syntax looks like this:

AUTH mechanism [initial-response]

Arguments:

  • mechanism: a string naming the SASL authentication mechanism 🔐
  • initial-response: an optional initial client response, like Section 3 of [RFC4422] describes 🧚. If it's there, it MUST be Base64 encoded (Section 4 of [RFC4648] has the deets), or it can be just the single character =, which means "I'm sending an empty initial response" 💖

Restrictions:

Once an AUTH command has finished successfully, no more AUTH commands may be issued in that same session. So after a successful AUTH, the server MUST reject any further AUTH commands with an -ERR reply. 🙅‍♀️

AUTH can only be given during the AUTHORIZATION state 🌸

Discussion:

The AUTH command starts a SASL authentication exchange between the client and the server ✨ The client picks the SASL mechanism with the first parameter. If the server supports that mechanism, it runs the SASL exchange to log the user in. It can also negotiate a security layer for the rest of the session, which is optional 🦋 If the server doesn't support the mechanism, it rejects the AUTH command with an -ERR reply.

The whole authentication exchange is a back-and-forth of server challenges and client responses. What those look like depends on the mechanism you picked 💜

A server challenge is sent as one line: a + character, then a single space, then a Base64 encoded string (Section 4 of [RFC4648]). That line MUST NOT contain any text other than the BASE64 encoded challenge 🙅‍♀️

A client response is a line with a Base64 encoded string. If the client wants to cancel the exchange, it sends a line with just a single *. If the server gets that, it MUST reject the AUTH command with an -ERR reply 💀

The optional initial-response argument is there to save a round trip, for mechanisms that support an initial client response 🚀 If you leave it out and the mechanism needs an initial client response, the server MUST keep things moving by sending an empty challenge (Section 3 of [RFC4422]). In POP3, an empty server challenge is just a line with a + followed by a single space, and it MUST NOT contain any other data 🍓

For the initial client response, the 255-octet limit on a single command (Section 4 of [RFC2449]) still applies 📏 If adding the initial response would make the AUTH command go over that length, the client MUST NOT use the initial-response parameter. It has to send its initial response after an empty challenge from the server instead (Section 3 of [RFC4422]) 😭

If the client needs to send a zero-length initial response, it MUST send it as a single equals sign (=). That means "the response is there, it just has no data" 🫶

If the client uses an initial-response argument with a SASL mechanism that doesn't support an initial client send, the server MUST reject the AUTH command with an -ERR reply 🙈

If the server can't Base64 decode a client response, it MUST reject the AUTH command with an -ERR reply. If the client can't Base64 decode any of the server's challenges, it MUST cancel the authentication with the * response. Servers and clients MUST reject (and not ignore) any character that isn't explicitly in the Base64 alphabet. They also MUST reject any sequence of Base64 characters where the pad character (=) shows up anywhere other than the end of the string. So =AAA and AAA=BBB are both a no-go 🚫

Apart from the initial client response, these Base64 strings can be any length, depending on the mechanism. Clients and servers MUST be able to handle the biggest encoded challenges and responses their supported mechanisms can generate. This requirement stands on its own, separate from any line-length limits the client or server has elsewhere in its protocol implementation 💪

If the server can't authenticate the client, it MUST reject the AUTH command with an -ERR reply. If the client finishes the exchange successfully, the server sends a +OK reply. On success, the POP3 session also moves into the TRANSACTION state 🎉

The authorization identity from the SASL exchange is a simple username. It SHOULD use the SASLprep profile (see [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to prep the names for matching ✨ If preparing the authorization identity fails, or it ends up as an empty string (unless it was sent as an empty string to begin with), the server MUST fail the authentication 😤

If a security layer gets negotiated during the SASL exchange, it kicks in for the client on the octet right after the CRLF that ends the client's last response. For the server, it kicks in right after the CRLF of its success reply 🔥

Once a security layer takes effect, the server MUST throw away any knowledge it got from the client that didn't come from the SASL negotiation itself. Same vibe for the client: it MUST discard any knowledge it got from the server, like the list of available POP3 service extensions 🧹

When both Transport Layer Security (TLS) (see [RFC4346]) and SASL security layers are active, the TLS encoding MUST be applied after the SASL encoding when sending data. (According to [RFC2595], STLS can only be issued before AUTH anyway 🙃)

Quick heads up: POP3 doesn't let extra data ride along with a successful outcome message (see Section 3.6 of [RFC4422]) 🙅‍♀️

The service name for this protocol's SASL profile is "pop" 🧚

If an AUTH command fails, the client can try a different mechanism or different credentials by sending another AUTH command (or by using one of the other POP3 authentication mechanisms) 🔄 And the server MUST act like the client never sent the AUTH command in the first place 👻

To keep things interoperable, client and server implementations of this extension MUST implement the PLAIN SASL mechanism [RFC4616] running over TLS [RFC2595] 🫶

A server implementation MUST have a configuration where it does NOT advertise or permit any plaintext password mechanisms, unless the STLS command has been used to negotiate a TLS session (see [RFC2595]). As RFC 4616 explains, this configuration SHOULD be the default one 🌈 Before a client uses a plaintext password mechanism over a TLS session, it MUST verify the TLS server certificate, as RFC 2595 requires in Section 2.4 🔐 Client and server implementations SHOULD also implement additional SASL mechanisms that don't send plaintext passwords, like the GSSAPI [RFC4752] mechanism 🦋

5. Formal Syntax 🎀

The syntax below uses the Augmented Backus-Naur Form notation from [RFC4234]. The rules CRLF, ALPHA, and DIGIT are imported from [RFC4234]. The sasl-mech rule is from [RFC4422] 📖

Unless noted otherwise, all alphabetic characters are case-insensitive. Using upper or lower case to define token strings is just for editorial clarity 💅 Implementations MUST accept these strings case-insensitively 🙌

auth-command     = "AUTH" SP sasl-mech [SP initial-response]
                   *(CRLF [base64]) [CRLF cancel-response] CRLF

initial-response = base64 / "="

cancel-response  = "*"

base64           = base64-terminal /
                   ( 1*(4base64-CHAR) [base64-terminal] )

base64-char      = ALPHA / DIGIT / "+" / "/"
                   ;; Case-sensitive

base64-terminal  = (2base64-char "==") / (3base64-char "=")

continue-req     = "+" SP [base64] CRLF

Also, the ABNF from [RFC2449] gets updated like this 🧁

response         =/ continue-req

6. Examples 🍓

Here's a client trying AUTH PLAIN (see [RFC4616]) under TLS, using the initial client response 🥰

     S: +OK pop.example.com BlurdyBlurp POP3 server ready
     C: CAPA
     S: +OK List of capabilities follows
     S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
     S: STLS
     S: IMPLEMENTATION BlurdyBlurp POP3 server
     S: .
     C: STLS
     S: +OK Begin TLS negotiation now
         (TLS negotiation proceeds, further commands protected by TLS
         layer)
     C: CAPA
     S: +OK List of capabilities follows
     S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
     S: IMPLEMENTATION BlurdyBlurp POP3 server
     S: .
     C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q=
     S: +OK Maildrop locked and ready

Here's another client attempting AUTH PLAIN under a TLS layer, but this time without the initial response. Some of the negotiation before the TLS layer got set up has been left out 🙈

         (TLS negotiation proceeds, further commands protected by TLS
         layer)
     C: CAPA
     S: +OK List of capabilities follows
     S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
     S: IMPLEMENTATION BlurdyBlurp POP3 server
     S: .
     C: AUTH PLAIN
         (note that there is a space following the '+' on the
         following line)
     S: +
     C: dGVzdAB0ZXN0AHRlc3Q=
     S: +OK Maildrop locked and ready

And this one uses a mechanism where the exchange starts with a server challenge. The long lines are broken up just for editorial clarity 🦄

      S: +OK pop.example.com BlurdyBlurp POP3 server ready
      C: CAPA
      S: +OK List of capabilities follows
      S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
      S: STLS
      S: IMPLEMENTATION BlurdyBlurp POP3 server
      S: .
      C: AUTH DIGEST-MD5
      S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
           RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
           cnNldD11dGYtOA==
      C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
         QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
         MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9In
         BvcC9lbHdvb2QuaW5ub3NvZnQuY29tIixyZXNwb25zZT1iMGQ1NmQyZjA1
         NGMyNGI2MjA3MjMyMjEwNjQ2OGRiOSxxb3A9YXV0aA==
      S: + cnNwYXV0aD0wYjk3MTQ2MmNlZjVlOGY5MzBkYjlhMzNiMDJmYzlhMA==
      C:
      S: +OK Maildrop locked and ready

7. Security Considerations 🔥

⚠️ Security issues are discussed throughout this document. Seriously, this is the part you can't skip. Read the whole thing, especially the parts about plaintext passwords and TLS. Your users' inboxes are on the line 😭

8. IANA Considerations ✨

okay so IANA has updated its site to point at this RFC instead of [RFC1734] 🎀 bestie, that's the update for the POP3 extension registry at http://www.iana.org/assignments/pop3-extension-mechanism, and also for the GSSAPI/SASL service name registry at http://www.iana.org/assignments/gssapi-service-names 🗂️💅

9. Acknowledgments 🫶

the authors gave a shoutout to John Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and everyone else who contributed to RFC 1734 and RFC 2554, because this document leans on those SO hard 😭🌸

the authors also thanked Ken Murchison, Randall Gellens, Alexey Melnikov, Mark Crispin, Arnt Gulbrandsen, Lisa Dusseault, Frank Ellermann, and Philip Guenther for reviewing it 🦋✨

10. Changes From RFC 1734, RFC 2449. 🔄

here's the glow-up list, bestie 💖

  1. updated references to newer versions of various specs, especially RFC 4422 📚
  2. the SASL-based semantics from RFC 2449 are now normative for the AUTH extension 👑 (normative means it's a MUST-level thing, no cap 💅)
  3. the proper behaviour and handling of initial client responses is now defined, with examples and references to SASL 🧚
  4. new minimum requirement of support for TLS+PLAIN 🔐
  5. the SASLprep profile SHOULD be used to prepare authorization identities 💜
  6. clarify that the TLS encoding should be applied after any encoding applied by SASL security layers 🎀
  7. note that the mechanism list can change after STLS 🦋
  8. explicitly mention that "=" means a zero-length initial response 🍓
  9. note that POP3 doesn't allow additional data to be sent with +OK 🙈

11. Normative References 📖

  • [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998.
  • [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
  • [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
  • [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
  • [RFC4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
  • [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
  • [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
  • [RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.

12. Informative References 📚

  • [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
  • [RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC 3206, February 2002.
  • [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
  • [RFC4752] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, November 2006.

Authors' Addresses 🧑‍💻

Robert Siemborski Google, Inc. 1600 Ampitheatre Parkway Mountain View, CA 94043

Phone: +1 650 623 6925 EMail: robsiemb@google.com

Abhijit Menon-Sen Oryx Mail Systems GmbH

EMail: ams@oryx.com

Copyright (C) The IETF Trust (2007).

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, THE IETF TRUST 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 currently provided by the Internet Society. 🌈

📦 where this page comes from