RFC 2554

SMTP Service Extension for Authentication

📅 published March 1999, from ietf

RFC 2554: SMTP Service Extension for Authentication 💌

Author: J. Myers, Netscape Communications 🦋 Category: Standards Track 🎀 Date: March 1999 🌸 Obsoletes / Updates: this one doesn't list anything it obsoletes or updates, so it's a fresh start ✨

okay so this is part 1 of 2 🫶

Status of This Memo ✨

okay so this doc is an Internet standards track protocol spec for the Internet community, and it wants feedback and suggestions for improvements 💖 if you want to know where it stands, check the current edition of the "Internet Official Protocol Standards" (STD 1), because that's the source of truth for the standardization state and status of this protocol 📜 and distribution of this memo is unlimited, so share it with everyone 🌈

Copyright (C) The Internet Society (1999). All Rights Reserved. 💅

1. Introduction 🎀

okay this is the big picture 💜 this doc defines an SMTP service extension [ESMTP] that lets an SMTP client tell the server which authentication mechanism it wants, run the authentication protocol exchange with the server, and (optionally!) negotiate a security layer for the protocol interactions that come after 🔐 it's basically a profile of the Simple Authentication and Security Layer [SASL], so it's built on top of that framework 🧚

2. Conventions Used in this Document 🌸

in the examples, "C:" means lines sent by the client and "S:" means lines sent by the server 💬

the key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS] 📖 these are the capital-letter words that carry real weight, so when you see them, take them seriously, bestie 👑

3. The Authentication service extension 🦋

okay here's the extension in six bullet points, so you can see exactly what it does ✨

  • (1) the name of the SMTP service extension is "Authentication" 🎀
  • (2) the EHLO keyword value associated with this extension is "AUTH" 💅
  • (3) the AUTH EHLO keyword contains, as a parameter, a space separated list of the names of supported SASL mechanisms 🌈
  • (4) a new SMTP verb "AUTH" is defined 🔥
  • (5) an optional parameter using the keyword "AUTH" is added to the MAIL FROM command, and it extends the maximum line length of the MAIL FROM command by 500 characters 📏
  • (6) this extension is appropriate for the submission protocol [SUBMIT] 🫶

4. The AUTH command 🔐

here's the main event, the AUTH command itself 💖 I'm going to go through it piece by piece, so grab a snack 🍓

Arguments:

okay so the AUTH command takes two things. first, a string identifying a SASL authentication mechanism. second, an optional base64-encoded response ✨

Restrictions:

ngl this part is super important 🙈 after an AUTH command has successfully completed, no more AUTH commands may be issued in the same session. so once you've authenticated, you're done for that session, periodt 💅 after a successful AUTH command completes, a server MUST reject any further AUTH commands with a 503 reply. no exceptions, that's the rule 😭

also, the AUTH command is not permitted during a mail transaction, so don't try to slide it in mid-message 🙅

Discussion:

the AUTH command is how the client tells the server "hey, I want to use this authentication mechanism" 🦋 if the server supports that mechanism, it runs an authentication protocol exchange to authenticate and identify the user. it can also, optionally, negotiate a security layer for the protocol interactions that come next ✨ if the server doesn't support the requested mechanism, it rejects the AUTH command with a 504 reply. rude, but clear 💀

the authentication protocol exchange is a series of server challenges and client answers, and the details depend on the specific mechanism 🌸 a server challenge (also called a ready response) is a 334 reply, and its text part contains a BASE64 encoded string. the client answer is a line containing a BASE64 encoded string 💜 if the client wants to cancel an authentication exchange, it sends a line with a single "*". if the server gets that answer, it MUST reject the AUTH command by sending a 501 reply 🙅‍♀️

the optional initial-response argument is there to save a round trip 🚀 it's for mechanisms that send no data in the initial challenge. when you use initial-response with one of those mechanisms, the empty initial challenge is never sent to the client, and the server treats the data in initial-response as if it had been sent in response to that empty challenge 🧚 here's the tricky bit: unlike a zero-length client answer to a 334 reply, a zero-length initial response is sent as a single equals sign ("="). and if the client uses initial-response with a mechanism that DOES send data in the initial challenge, the server rejects the AUTH command with a 535 reply 🫠

if the server can't BASE64 decode the argument, it rejects the AUTH command with a 501 reply 🙃 if the server rejects the authentication data, it SHOULD reject the AUTH command with a 535 reply, unless a more specific error code (like one listed in section 6) is appropriate 💅 and if the client successfully completes the authentication exchange, the SMTP server issues a 235 reply, which is the big win 🎉

the service name for this protocol's profile of SASL is "smtp" 🦋

now the security layer stuff 🔐 if a security layer gets negotiated through the SASL authentication exchange, it takes effect immediately after the CRLF that ends the exchange for the client, and after the CRLF of the success reply for the server. once a security layer takes effect, the SMTP protocol resets to the initial state (the state SMTP is in after a server issues a 220 service ready greeting) 🔄 the server MUST discard any knowledge it got from the client that wasn't obtained from the SASL negotiation itself, such as the argument to the EHLO command 🗑️ the client MUST discard any knowledge it got from the server that wasn't obtained from the SASL negotiation itself, such as the list of SMTP service extensions (with one exception: a client MAY compare the list of advertised SASL mechanisms before and after authentication, so it can detect an active down-negotiation attack 🕵️‍♀️). and the client SHOULD send an EHLO command as the first command after a successful SASL negotiation that turns on a security layer ✨

the server isn't required to support any particular authentication mechanism, and authentication mechanisms aren't required to support any security layers either 💜 if an AUTH command fails, the client may try another mechanism by issuing another AUTH command 🌈 and if an AUTH command fails, the server MUST behave the same as if the client had never issued it at all 🙈

last but not least, the BASE64 string can be arbitrarily long 📏 clients and servers MUST be able to support challenges and responses as long as the ones their authentication mechanisms generate, no matter what line length limits they have in other parts of their protocol implementation 💖

Examples:

here's what a real exchange looks like, bestie 👀

S: 220 smtp.example.com ESMTP server ready
C: EHLO jgm.example.com
S: 250-smtp.example.com
S: 250 AUTH CRAM-MD5 DIGEST-MD5
C: AUTH FOOBAR
S: 504 Unrecognized authentication type.
C: AUTH CRAM-MD5
S: 334
PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful.

the client tried a made-up mechanism first and got a 504, then went with CRAM-MD5, got its challenge in the 334, answered it, and the server said 235 🎉 that's the whole vibe, iconic 👑

(part 2 coming up next: Section 5 and onward 🌸)

7. Formal Syntax 📐✨

okay so the grammar is up next, and it's written in ABNF [ABNF] 💅. bestie, the one thing you need to know is that everything alphabetic is case-insensitive, unless it's noted otherwise. Using uppercase or lowercase for token strings is just to make things easier to read. Implementations MUST accept these strings case-insensitively 🫶.

UPALPHA         = %x41-5A            ;; Uppercase: A-Z

LOALPHA         = %x61-7A            ;; Lowercase: a-z

ALPHA           = UPALPHA / LOALPHA  ;; case insensitive

DIGIT           = %x30-39            ;; Digits 0-9

HEXDIGIT        = %x41-46 / DIGIT    ;; hexidecimal digit (uppercase)

hexchar         = "+" HEXDIGIT HEXDIGIT

xchar           = %x21-2A / %x2C-3C / %x3E-7E
                  ;; US-ASCII except for "+", "=", SPACE and CTL

xtext           = *(xchar / hexchar)

AUTH_CHAR       = ALPHA / DIGIT / "-" / "_"

auth_type       = 1*20AUTH_CHAR

auth_command    = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
                  *(CRLF [base64]) CRLF

auth_param      = "AUTH=" xtext
                    ;; The decoded form of the xtext MUST be either
                    ;; an addr-spec or the two characters "<>"

base64          = base64_terminal /
                  ( 1*(4base64_CHAR) [base64_terminal] )

base64_char     = UPALPHA / LOALPHA / DIGIT / "+" / "/"
                  ;; Case-sensitive

base64_terminal = (2base64_char "==") / (3base64_char "=")

continue_req    = "334" SPACE [base64] CRLF
CR              = %x0C           ;; ASCII CR, carriage return

CRLF            = CR LF

CTL             = %x00-1F / %x7F ;; any ASCII control character and DEL

LF              = %x0A           ;; ASCII LF, line feed

SPACE           = %x20           ;; ASCII SP, space
⚠️ heads up: the auth_param rule is where the decoded xtext MUST be either an addr-spec or the two characters "<>". that's the bit that makes the envelope stuff work, so don't skip it 👀

8. References 📚🎀

okay bestie, here are all the references the spec leans on. I'm keeping every tag and every detail exactly as written so you can look them up 🧚

  • [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
  • [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
  • [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995.
  • [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
  • [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
  • [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
  • [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
  • [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.

9. Security Considerations 🔐💀

okay this part is seriously important, so listen up 👑. Security issues are discussed all throughout this memo, but here's the big stuff.

If a client uses this extension to get an encrypted tunnel through an insecure network to a cooperating server, it needs to be set up to never send mail to that server unless the connection is mutually authenticated and encrypted 🚫. If it isn't, an attacker could steal the client's mail by hijacking the SMTP connection and either pretending the server doesn't support the Authentication extension, or making every AUTH command fail. Yikes 😭.

Before the SASL negotiation has started, everything is sent in the clear, and an active attacker can modify it 👀. That's why clients and servers MUST discard any knowledge they got before the SASL negotiation began, once a SASL negotiation finishes with a security layer in place 🫶.

This mechanism does not protect the TCP port. So an active attacker can redirect a relay connection attempt to the submission port [SUBMIT]. The AUTH=<> parameter stops that attack from making a relayed message, which has no envelope authentication, pick up the relay client's authentication 🛡️.

A message submission client may require the user to authenticate whenever a suitable SASL mechanism is advertised. So it may not be desirable for a submission server [SUBMIT] to advertise a SASL mechanism when using that mechanism gives the client no benefits over anonymous submission 🤷‍♀️.

This extension is not meant to replace end-to-end message signature and encryption systems like S/MIME or PGP, and it's not meant to be used instead of them 🙅‍♀️. It solves a different problem than end-to-end systems, and the key differences are:

  1. it is generally useful only within a trusted enclave
  2. it protects the entire envelope of a message, not just the message's body.
  3. it authenticates the message submission, not authorship of the message content
  4. it can give the sender some assurance the message was delivered to the next hop in the case where the sender mutually authenticates with the next hop and negotiates an appropriate security layer.

Additional security considerations are mentioned in the SASL specification [SASL] 📖✨.

10. Author's Address 🖊️

the author is John Gardiner Myers, and the contact details are kept exactly as they were written:

John Gardiner Myers
Netscape Communications
501 East Middlefield Road
Mail Stop MV-029
Mountain View, CA 94043

EMail: jgmyers@netscape.com

this legal bit is kept exactly as written, word for word, so nothing gets lost 🎀:

Copyright (C) The Internet Society (1999).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.

That's the whole RFC, bestie! 🌈💖 You're officially an AUTH expert now 💅✨

📦 where this page comes from