From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4954.txt | 1123 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1123 insertions(+) create mode 100644 doc/rfc/rfc4954.txt (limited to 'doc/rfc/rfc4954.txt') diff --git a/doc/rfc/rfc4954.txt b/doc/rfc/rfc4954.txt new file mode 100644 index 0000000..668d738 --- /dev/null +++ b/doc/rfc/rfc4954.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group R. Siemborski, Ed. +Request for Comments: 4954 Google, Inc. +Obsoletes: 2554 A. Melnikov, Ed. +Updates: 3463 Isode Limited +Category: Standards Track July 2007 + + + SMTP Service Extension for Authentication + +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 IETF Trust (2007). + +Abstract + + This document defines a Simple Mail Transport Protocol (SMTP) + extension whereby an SMTP client may indicate an authentication + mechanism to the server, perform an authentication protocol exchange, + and optionally negotiate a security layer for subsequent protocol + interactions during this session. This extension includes a profile + of the Simple Authentication and Security Layer (SASL) for SMTP. + + This document obsoletes RFC 2554. + + + + + + + + + + + + + + + + + + + + +Siemborski & Melnikov Standards Track [Page 1] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. How to Read This Document .......................................2 + 3. The Authentication Service Extension ............................3 + 4. The AUTH Command ................................................3 + 4.1. Examples ...................................................7 + 5. The AUTH Parameter to the MAIL FROM command .....................9 + 5.1. Examples ..................................................10 + 6. Status Codes ...................................................11 + 7. Additional requirements on servers .............................12 + 8. Formal Syntax ..................................................13 + 9. Security Considerations ........................................14 + 10. IANA Considerations ...........................................15 + 11. Normative References ..........................................15 + 12. Informative References ........................................16 + 13. Acknowledgments ...............................................17 + 14. Additional Requirements When Using SASL PLAIN over TLS ........17 + 15. Changes since RFC 2554 ........................................18 + +1. Introduction + + This document defines a Simple Mail Transport Protocol (SMTP) + extension whereby an SMTP client may indicate an authentication + mechanism to the server, perform an authentication protocol exchange, + optionally negotiate a security layer for subsequent protocol + interactions during this session and, during a mail transaction, + optionally specify a mailbox associated with the identity that + submitted the message to the mail delivery system. + + This extension includes a profile of the Simple Authentication and + Security Layer (SASL) for SMTP. + + When compared to RFC 2554, this document deprecates use of the 538 + response code, adds a new Enhanced Status Code, adds a requirement to + support SASLprep profile for preparing authorization identities, + recommends use of RFC 3848 transmission types in the Received trace + header field, and clarifies interaction with SMTP PIPELINING + [PIPELINING] extension. + +2. How to Read 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 [KEYWORDS]. + + In examples, "C:" and "S:" indicate lines sent by the client and + server, respectively. + + + +Siemborski & Melnikov Standards Track [Page 2] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + +3. The Authentication Service Extension + + 1. The name of this [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 available [SASL] mechanisms. The list of + available mechanisms MAY change after a successful STARTTLS + command [SMTP-TLS]. + + 4. A new [SMTP] verb "AUTH" is defined. + + 5. An optional parameter using the keyword "AUTH" is added to the + MAIL FROM command, and 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 + + AUTH mechanism [initial-response] + + Arguments: + mechanism: A string identifying a [SASL] authentication + mechanism. + + initial-response: An optional initial client response. If + present, this response MUST be encoded as described in Section + 4 of [BASE64] or contain a single character "=". + + Restrictions: + After an AUTH command has been successfully completed, no more + AUTH commands may be issued in the same session. After a + successful AUTH command completes, a server MUST reject any + further AUTH commands with a 503 reply. + + The AUTH command is not permitted during a mail transaction. + An AUTH command issued during a mail transaction MUST be + rejected with a 503 reply. + + Discussion: + The AUTH command initiates a [SASL] authentication exchange + between the client and the server. The client identifies the + SASL mechanism to use with the first parameter of the AUTH + command. If the server supports the requested authentication + mechanism, it performs the SASL exchange to authenticate the + + + +Siemborski & Melnikov Standards Track [Page 3] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + + user. Optionally, it also negotiates a security layer for + subsequent protocol interactions during this session. If the + requested authentication mechanism is invalid (e.g., is not + supported or requires an encryption layer), the server rejects + the AUTH command with a 504 reply. If the server supports the + [ESMTP-CODES] extension, it SHOULD return a 5.5.4 enhanced + response code. + + The SASL authentication exchange consists of a series of + server challenges and client responses that are specific to + the chosen [SASL] mechanism. + + A server challenge is sent as a 334 reply with the text part + containing the [BASE64] encoded string supplied by the SASL + mechanism. This challenge MUST NOT contain any text other + than the BASE64 encoded challenge. + + A client response consists of a line containing a [BASE64] + encoded string. If the client wishes to cancel the + authentication exchange, it issues a line with a single "*". + If the server receives such a response, it MUST reject the + AUTH command by sending a 501 reply. + + The optional initial response argument to the AUTH command is + used to save a round-trip when using authentication mechanisms + that support an initial client response. If the initial + response argument is omitted and the chosen mechanism requires + an initial client response, the server MUST proceed as defined + in Section 5.1 of [SASL]. In SMTP, a server challenge that + contains no data is defined as a 334 reply with no text part. + Note that there is still a space following the reply code, so + the complete response line is "334 ". + + Note that the AUTH command is still subject to the line length + limitations defined in [SMTP]. If use of the initial response + argument would cause the AUTH command to exceed this length, + the client MUST NOT use the initial response parameter (and + instead proceed as defined in Section 5.1 of [SASL]). + + If the client is transmitting an initial response of zero + length, it MUST instead transmit the response as a single + equals sign ("="). This indicates that the response is + present, but contains no data. + + If the client uses an initial-response argument to the AUTH + command with a SASL mechanism in which the client does not + begin the authentication exchange, the server MUST reject the + + + + +Siemborski & Melnikov Standards Track [Page 4] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + + AUTH command with a 501 reply. Servers using the enhanced + status codes extension [ESMTP-CODES] SHOULD return an enhanced + status code of 5.7.0 in this case. + + If the server cannot [BASE64] decode any client response, it + MUST reject the AUTH command with a 501 reply (and an enhanced + status code of 5.5.2). If the client cannot BASE64 decode any + of the server's challenges, it MUST cancel the authentication + using the "*" response. In particular, servers and clients + MUST reject (and not ignore) any character not explicitly + allowed by the BASE64 alphabet, and MUST reject any sequence + of BASE64 characters that contains the pad character ('=') + anywhere other than the end of the string (e.g., "=AAA" and + "AAA=BBB" are not allowed). + + Note that these [BASE64] strings can be much longer than + normal SMTP commands. Clients and servers MUST be able to + handle the maximum encoded size of challenges and responses + generated by their supported authentication mechanisms. This + requirement is independent of any line length limitations the + client or server may have in other parts of its protocol + implementation. (At the time of writing of this document, + 12288 octets is considered to be a sufficient line length + limit for handling of deployed authentication mechanisms.) + If, during an authentication exchange, the server receives a + line that is longer than the server's authentication buffer, + the server fails the AUTH command with the 500 reply. Servers + using the enhanced status codes extension [ESMTP-CODES] SHOULD + return an enhanced status code of 5.5.6 in this case. + + The authorization identity generated by this [SASL] exchange + is a "simple username" (in the sense defined in [SASLprep]), + and both client and server SHOULD (*) use the [SASLprep] + profile of the [StringPrep] algorithm to prepare these names + for transmission or comparison. If preparation of the + authorization identity fails or results in an empty string + (unless it was transmitted as the empty string), the server + MUST fail the authentication. + + (*) Note: Future revision of this specification may change this + requirement to MUST. Currently, the SHOULD is used in order to + avoid breaking the majority of existing implementations. + + If the server is unable to authenticate the client, it SHOULD reject + the AUTH command with a 535 reply unless a more specific error code + is appropriate. Should the client successfully complete the + exchange, the SMTP server issues a 235 reply. (Note that the SMTP + protocol doesn't support the SASL feature of returning additional + + + +Siemborski & Melnikov Standards Track [Page 5] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + + data with a successful outcome.) These status codes, along with + others defined by this extension, are discussed in Section 6 of this + document. + + If a security layer is negotiated during the SASL exchange, it takes + effect for the client on the octet immediately following the CRLF + that concludes the last response generated by the client. For the + server, it takes effect immediately following the CRLF of its success + reply. + + When a security layer takes effect, the SMTP protocol is reset to the + initial state (the state in SMTP after a server issues a 220 service + ready greeting). The server MUST discard any knowledge obtained from + the client, such as the EHLO argument, which was not obtained from + the SASL negotiation itself. Likewise, the client MUST discard any + knowledge obtained from the server, such as the list of SMTP service + extensions, which was not obtained from the SASL negotiation itself. + (Note that a client MAY compare the advertised SASL mechanisms before + and after authentication in order to detect an active down- + negotiation attack). + + The client SHOULD send an EHLO command as the first command after a + successful SASL negotiation that results in the enabling of a + security layer. + + When an entity (whether it is the client or the server end) is + sending data, and both [TLS] and SASL security layers are in effect, + the TLS encoding MUST be applied after the SASL encoding, regardless + of the order in which the layers were negotiated. + + The service name specified by this protocol's profile of SASL is + "smtp". This service name is also to be used for the [SUBMIT] + protocol. + + If an AUTH command fails, the client MAY proceed without + authentication. Alternatively, the client MAY try another + authentication mechanism or present different credentials by issuing + another AUTH + + Note: A server implementation MUST implement a configuration in which + it does NOT permit any plaintext password mechanisms, unless either + the STARTTLS [SMTP-TLS] command has been negotiated or some other + mechanism that protects the session from password snooping has been + provided. Server sites SHOULD NOT use any configuration which + permits a plaintext password mechanism without such a protection + mechanism against password snooping. + + + + + +Siemborski & Melnikov Standards Track [Page 6] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + + To ensure interoperability, client and server implementations of this + extension MUST implement the [PLAIN] SASL mechanism running over TLS + [TLS] [SMTP-TLS]. See also Section 15 for additional requirements on + implementations of [PLAIN] over [TLS]. + + Note that many existing client and server implementations implement + CRAM-MD5 [CRAM-MD5] SASL mechanism. In order to ensure + interoperability with deployed software, new implementations MAY + implement it; however, implementations should be aware that this SASL + mechanism doesn't provide any server authentication. Note that at + the time of writing of this document the SASL Working Group is + working on several replacement SASL mechanisms that provide server + authentication and other features. + + When the AUTH command is used together with the [PIPELINING] + extension, it MUST be the last command in a pipelined group of + commands. The only exception to this rule is when the AUTH command + contains an initial response for a SASL mechanism that allows the + client to send data first, the SASL mechanism is known to complete in + one round-trip, and a security layer is not negotiated by the client. + Two examples of such SASL mechanisms are PLAIN [PLAIN] and EXTERNAL + [SASL]. + +4.1. Examples + + Here is an example of a client attempting AUTH using the [PLAIN] SASL + mechanism under a TLS layer, and making use of the initial client + response: + + S: 220-smtp.example.com ESMTP Server + C: EHLO client.example.com + S: 250-smtp.example.com Hello client.example.com + S: 250-AUTH GSSAPI DIGEST-MD5 + S: 250-ENHANCEDSTATUSCODES + S: 250 STARTTLS + C: STARTTLS + S: 220 Ready to start TLS + ... TLS negotiation proceeds, further commands + protected by TLS layer ... + C: EHLO client.example.com + S: 250-smtp.example.com Hello client.example.com + S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN + C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ= + S: 235 2.7.0 Authentication successful + + Here is another client that is attempting AUTH PLAIN under a TLS + layer, this time without the initial response. Parts of the + negotiation before the TLS layer was established have been omitted: + + + +Siemborski & Melnikov Standards Track [Page 7] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + + ... TLS negotiation proceeds, further commands + protected by TLS layer ... + C: EHLO client.example.com + S: 250-smtp.example.com Hello client.example.com + S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN + C: AUTH PLAIN + (note: there is a single space following the 334 + on the following line) + S: 334 + C: dGVzdAB0ZXN0ADEyMzQ= + S: 235 2.7.0 Authentication successful + + Here is an example using CRAM-MD5 [CRAM-MD5], a mechanism in which + the client does not begin the authentication exchange, and includes a + server challenge: + + S: 220-smtp.example.com ESMTP Server + C: EHLO client.example.com + S: 250-smtp.example.com Hello client.example.com + S: 250-AUTH DIGEST-MD5 CRAM-MD5 + S: 250-ENHANCEDSTATUSCODES + S: 250 STARTTLS + C: AUTH CRAM-MD5 + S: 334 PDQxOTI5NDIzNDEuMTI4Mjg0NzJAc291cmNlZm91ci5hbmRyZXcuY211LmVk + dT4= + C: cmpzMyBlYzNhNTlmZWQzOTVhYmExZWM2MzY3YzRmNGI0MWFjMA== + S: 235 2.7.0 Authentication successful + + Here is an example of a client attempting AUTH EXTERNAL under TLS, + using the derived authorization ID (and thus a zero-length initial + client response). + + S: 220-smtp.example.com ESMTP Server + C: EHLO client.example.com + S: 250-smtp.example.com Hello client.example.com + S: 250-AUTH GSSAPI DIGEST-MD5 + S: 250-ENHANCEDSTATUSCODES + S: 250 STARTTLS + C: STARTTLS + S: 220 Ready to start TLS + ... TLS negotiation proceeds, further commands + protected by TLS layer ... + C: EHLO client.example.com + S: 250-smtp.example.com Hello client.example.com + S: 250 AUTH EXTERNAL GSSAPI DIGEST-MD5 PLAIN + C: AUTH EXTERNAL = + S: 235 2.7.0 Authentication successful + + + + +Siemborski & Melnikov Standards Track [Page 8] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + +5. The AUTH Parameter to the MAIL FROM command + + AUTH=mailbox + + Arguments: + A (see Section 4.1.2 of [SMTP]) that is associated + with the identity that submitted the message to the delivery + system, or the two character sequence "<>" indicating such an + identity is unknown or insufficiently authenticated. To comply + with restrictions imposed on ESMTP parameters, the is + encoded inside an xtext. The syntax of an xtext is described in + Section 4 of [ESMTP-DSN]. + + Note: + For the purposes of this discussion, "authenticated identity" + refers to the identity (if any) derived from the authorization + identity of previous AUTH command, while the terms "authorized + identity" and "supplied " refer to the sender identity + that is being associated with a particular message. Note that + one authenticated identity may be able to identify messages as + being sent by any number of authorized identities within a + single session. For example, this may be the case when an SMTP + server (one authenticated identity) is processing its queue + (many messages with distinct authorized identities). + + Discussion: + The optional AUTH parameter to the MAIL FROM command allows + cooperating agents in a trusted environment to communicate the + authorization identity associated with individual messages. + + If the server trusts the authenticated identity of the client to + assert that the message was originally submitted by the supplied + , then the server SHOULD supply the same in + an AUTH parameter when relaying the message to any other server + which supports the AUTH extension. + + For this reason, servers that advertise support for this + extension MUST support the AUTH parameter to the MAIL FROM + command even when the client has not authenticated itself to the + server. + + A MAIL FROM parameter of AUTH=<> indicates that the original + submitter of the message is not known. The server MUST NOT + treat the message as having been originally submitted by the + authenticated identity that resulted from the AUTH command. + + + + + + +Siemborski & Melnikov Standards Track [Page 9] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + + If the AUTH parameter to the MAIL FROM command is not supplied, + the client has authenticated, and the server believes the + message is an original submission, the server MAY generate a + from the user's authenticated identity for use in an + AUTH parameter when relaying the message to any server which + supports the AUTH extension. The generated is + implementation specific, but it MUST conform to the syntax of + [SMTP]. If the implementation cannot generate a valid + , it MUST transmit AUTH=<> when relaying this message. + + If the server does not sufficiently trust the authenticated + identity of the client, or if the client is not authenticated, + then the server MUST behave as if the AUTH=<> parameter was + supplied. The server MAY, however, write the value of any + supplied AUTH parameter to a log file. + + If an AUTH=<> parameter was supplied, either explicitly or due + to the requirement in the previous paragraph, then the server + MUST supply the AUTH=<> parameter when relaying the message to + any server which it has authenticated to using the AUTH + extension. + + A server MAY treat expansion of a mailing list as a new + submission, setting the AUTH parameter to the mailing list + address or mailing list administration address when relaying the + message to list subscribers. + + Note that an implementation which is hard-coded to treat all + clients as being insufficiently trusted is compliant with this + specification. In that case, the implementation does nothing + more than parse and discard syntactically valid AUTH parameters + to the MAIL FROM command, and supply AUTH=<> parameters to any + servers that it authenticates to. + +5.1. Examples + + An example where the original identity of the sender is trusted and + known: + + C: MAIL FROM: AUTH=e+3Dmc2@example.com + S: 250 OK + + One example where the identity of the sender is not trusted or is + otherwise being suppressed by the client: + + C: MAIL FROM: AUTH=<> + S: 250 OK + + + + +Siemborski & Melnikov Standards Track [Page 10] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + +6. Status Codes + + The following error codes may be used to indicate various success or + failure conditions. Servers that return enhanced status codes + [ESMTP-CODES] SHOULD use the enhanced codes suggested here. + + 235 2.7.0 Authentication Succeeded + + This response to the AUTH command indicates that the authentication + was successful. + + 432 4.7.12 A password transition is needed + + This response to the AUTH command indicates that the user needs to + transition to the selected authentication mechanism. This is + typically done by authenticating once using the [PLAIN] + authentication mechanism. The selected mechanism SHOULD then work + for authentications in subsequent sessions. + + 454 4.7.0 Temporary authentication failure + + This response to the AUTH command indicates that the authentication + failed due to a temporary server failure. The client SHOULD NOT + prompt the user for another password in this case, and should instead + notify the user of server failure. + + 534 5.7.9 Authentication mechanism is too weak + + This response to the AUTH command indicates that the selected + authentication mechanism is weaker than server policy permits for + that user. The client SHOULD retry with a new authentication + mechanism. + + 535 5.7.8 Authentication credentials invalid + + This response to the AUTH command indicates that the authentication + failed due to invalid or insufficient authentication credentials. In + this case, the client SHOULD ask the user to supply new credentials + (such as by presenting a password dialog box). + + 500 5.5.6 Authentication Exchange line is too long + + This response to the AUTH command indicates that the authentication + failed due to the client sending a [BASE64] response that is longer + than the maximum buffer size available for the currently selected + SASL mechanism. + + + + + +Siemborski & Melnikov Standards Track [Page 11] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + + 530 5.7.0 Authentication required + + This response SHOULD be returned by any command other than AUTH, + EHLO, HELO, NOOP, RSET, or QUIT when server policy requires + authentication in order to perform the requested action and + authentication is not currently in force. + + 538 5.7.11 Encryption required for requested authentication + mechanism + + This response to the AUTH command indicates that the selected + authentication mechanism may only be used when the underlying SMTP + connection is encrypted. Note that this response code is documented + here for historical purposes only. Modern implementations SHOULD NOT + advertise mechanisms that are not permitted due to lack of + encryption, unless an encryption layer of sufficient strength is + currently being employed. + + This document adds several new enhanced status codes to the list + defined in [ENHANCED]: + + The following 3 Enhanced Status Codes were defined above: + + 5.7.8 Authentication credentials invalid + 5.7.9 Authentication mechanism is too weak + 5.7.11 Encryption required for requested authentication mechanism + + X.5.6 Authentication Exchange line is too long + + This enhanced status code SHOULD be returned when the server fails + the AUTH command due to the client sending a [BASE64] response which + is longer than the maximum buffer size available for the currently + selected SASL mechanism. This is useful for both permanent and + persistent transient errors. + +7. Additional Requirements on Servers + + As described in Section 4.4 of [SMTP], an SMTP server that receives a + message for delivery or further processing MUST insert the + "Received:" header field at the beginning of the message content. + This document places additional requirements on the content of a + generated "Received:" header field. Upon successful authentication, + a server SHOULD use the "ESMTPA" or the "ESMTPSA" [SMTP-TT] (when + appropriate) keyword in the "with" clause of the Received header + field. + + + + + + +Siemborski & Melnikov Standards Track [Page 12] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + +8. Formal Syntax + + The following syntax specification uses the Augmented Backus-Naur + Form notation as specified in [ABNF]. Non-terminals referenced but + not defined below are as defined by [ABNF] or [SASL]. The non- + terminal is defined in [SMTP]. + + Except as noted otherwise, all alphabetic characters are case- + insensitive. The use of upper or lower case characters to define + token strings is for editorial clarity only. Implementations MUST + accept these strings in a case-insensitive fashion. + + hexchar = "+" HEXDIG HEXDIG + + xchar = %x21-2A / %x2C-3C / %x3E-7E + ;; US-ASCII except for "+", "=", SP, and CTL + + xtext = *(xchar / hexchar) + ;; non-US-ASCII is only allowed as hexchar + + auth-command = "AUTH" SP sasl-mech [SP initial-response] + *(CRLF [base64]) [CRLF cancel-response] + CRLF + ;; is defined in [SASL] + + auth-param = "AUTH=" xtext + ;; Parameter to the MAIL FROM command. + ;; This non-terminal complies with + ;; syntax defined by esmtp-param [SMTP]. + ;; + ;; The decoded form of the xtext MUST be + ;; either a or the two + ;; characters "<>" + + base64 = base64-terminal / + ( 1*(4base64-char) [base64-terminal] ) + + base64-char = ALPHA / DIGIT / "+" / "/" + ;; Case-sensitive + + base64-terminal = (2base64-char "==") / (3base64-char "=") + + continue-req = "334" SP [base64] CRLF + ;; Intermediate response to the AUTH + ;; command. + ;; This non-terminal complies with + ;; syntax defined by Reply-line [SMTP]. + + + + +Siemborski & Melnikov Standards Track [Page 13] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + + initial-response= base64 / "=" + + cancel-response = "*" + +9. Security Considerations + + Security issues are discussed throughout this memo. + + If a client uses this extension to get an encrypted tunnel through an + insecure network to a cooperating server, it needs to be configured + to never send mail to that server when the connection is not mutually + authenticated and encrypted. Otherwise, an attacker could steal the + client's mail by hijacking the [SMTP] connection and either + pretending the server does not support the Authentication extension + or causing all AUTH commands to fail. + + Before the [SASL] negotiation has begun, any protocol interactions + are performed in the clear and may be modified by an active attacker. + For this reason, clients and servers MUST discard any knowledge + obtained prior to the start of the SASL negotiation upon the + establishment of a security layer. + + This mechanism does not protect the TCP port, so an active attacker + may redirect a relay connection attempt (i.e., a connection between + two Mail Transfer Agents (MTAs)) to the submission port [SUBMIT]. + The AUTH=<> parameter prevents such an attack from causing a relayed + message and, in the absence of other envelope authentication, from + picking up the authentication of the relay client. + + A message submission client may require the user to authenticate + whenever a suitable [SASL] mechanism is advertised. Therefore, it + may not be desirable for a submission server [SUBMIT] to advertise a + SASL mechanism when use of that mechanism grants the clients no + benefits over anonymous submission. + + Servers MAY implement a policy whereby the connection is dropped + after a number of failed authentication attempts. If they do so, + they SHOULD NOT drop the connection until at least 3 attempts to + authenticate have failed. + + If an implementation supports SASL mechanisms that are vulnerable to + passive eavesdropping attacks (such as [PLAIN]), then the + implementation MUST support at least one configuration where these + SASL mechanisms are not advertised or used without the presence of an + external security layer such as [TLS]. + + + + + + +Siemborski & Melnikov Standards Track [Page 14] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + + This extension is not intended to replace or be used instead of end- + to-end message signature and encryption systems such as [S/MIME] or + [PGP]. This extension addresses a different problem than end-to-end + systems; it has the following key differences: + + 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. When mutual authentication is used along with a security layer, + it can give the sender some assurance that the message was + successfully delivered to the next hop. + + Additional security considerations are mentioned in the [SASL] + specification. Additional security considerations specific to a + particular SASL mechanism are described in the relevant + specification. Additional security considerations for [PLAIN] over + [TLS] are mentioned in Section 15 of this document. + +10. IANA Considerations + + IANA updated the entry for the "smtp" SASL protocol name to point at + this document. + + IANA updated the registration of the Authentication SMTP service + extension as defined in Section 3 of this document. This registry is + currently located at . + +11. Normative References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, October 2006. + + [ESMTP-CODES] Freed, N., "SMTP Service Extension for Returning + Enhanced Error Codes", RFC 2034, October 1996. + + [ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC + 3463, January 2003. + + + + + +Siemborski & Melnikov Standards Track [Page 15] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + + [ESMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) + Service Extension Delivery Status Notifications + (DSNs)", RFC 3461, January 2003. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication + and Security Layer (SASL)", RFC 4422, June 2006. + + [SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User + Names and Passwords", RFC 4013, February 2005. + + [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP + over Transport Layer Security", RFC 3207, February + 2002. + + [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of + Internationalized Strings ("stringprep")", RFC 3454, + December 2002. + + [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for + Mail", RFC 4409, April 2006. + + [SMTP-TT] Newman, C., "ESMTP and LMTP Transmission Types + Registration", RFC 3848, July 2004. + + [PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and + Security Layer (SASL) Mechanism", RFC 4616, August + 2006. + + [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + +12. Informative References + + [PGP] Elkins, M., "MIME Security with Pretty Good Privacy + (PGP)", RFC 2015, October 1996. + + [S/MIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail + Extensions (S/MIME) Version 3.1 Message Specification", + RFC 3851, July 2004. + + + + +Siemborski & Melnikov Standards Track [Page 16] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + + [TLS] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.1", RFC 4346, April + 2006. + + [PIPELINING] Freed, N., "SMTP Service Extension for Command + Pipelining", STD 60, RFC 2920, September 2000. + + [CRAM-MD5] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP + AUTHorize Extension for Simple Challenge/Response", RFC + 2195, September 1997. + +13. Acknowledgments + + The editors would like to acknowledge the contributions of John Myers + and other contributors to RFC 2554, on which this document draws from + heavily. + + The editors would also like to thank Ken Murchison, Mark Crispin, + Chris Newman, David Wilson, Dave Cridland, Frank Ellermann, Ned + Freed, John Klensin, Tony Finch, Abhijit Menon-Sen, Philip Guenther, + Sam Hartman, Russ Housley, Cullen Jennings, and Lisa Dusseault for + the time they devoted to reviewing of this document and/or for the + comments received. + +14. Additional Requirements When Using SASL PLAIN over TLS + + This section is normative for SMTP implementations that support SASL + [PLAIN] over [TLS]. + + If an SMTP client is willing to use SASL PLAIN over TLS to + authenticate to the SMTP server, the client verifies the server + certificate according to the rules of [X509]. If the server has not + provided any certificate, or if the certificate verification fails, + the client MUST NOT attempt to authenticate using the SASL PLAIN + mechanism. + + After a successful [TLS] negotiation, the client MUST check its + understanding of the server hostname against the server's identity as + presented in the server Certificate message, in order to prevent + man-in-the-middle attacks. If the match fails, the client MUST NOT + attempt to authenticate using the SASL PLAIN mechanism. Matching is + performed according to the following rules: + + The client MUST use the server hostname it used to open the + connection as the value to compare against the server name as + expressed in the server certificate. The client MUST NOT use + + + + + +Siemborski & Melnikov Standards Track [Page 17] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + + any form of the server hostname derived from an insecure remote + source (e.g., insecure DNS lookup). CNAME canonicalization is + not done. + + If a subjectAltName extension of type dNSName is present in the + certificate, it SHOULD be used as the source of the server's + identity. + + Matching is case-insensitive. + + A "*" wildcard character MAY be used as the leftmost name + component in the certificate. For example, *.example.com would + match a.example.com, foo.example.com, etc., but would not match + example.com. + + If the certificate contains multiple names (e.g., more than one + dNSName field), then a match with any one of the fields is + considered acceptable. + +15. Changes since RFC 2554 + + 1. Clarified that servers MUST support the use of the AUTH=mailbox + parameter to MAIL FROM, even when the client is not + authenticated. + + 2. Clarified the initial-client-send requirements, and give + additional examples. + + 3. Updated references to newer versions of various specifications. + + 4. Required SASL PLAIN (over TLS) as mandatory-to-implement. + + 5. Clarified that the mechanism list can change. + + 6. Deprecated the use of the 538 response code. + + 7. Added the use of the SASLprep profile for preparing authorization + identities. + + 8. Substantial cleanup of response codes and indicated suggested + enhanced response codes. Also indicated what response codes + should result in a client prompting the user for new credentials. + + 9. Updated ABNF section to use RFC 4234. + + 10. Clarified interaction with SMTP PIPELINING extension. + + 11. Added a reference to RFC 3848. + + + +Siemborski & Melnikov Standards Track [Page 18] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + + 12. Added a new Enhanced Status Code for "authentication line too + long" case. + + 13. Other general editorial clarifications. + +Editors' Addresses + + Robert Siemborski + Google, Inc. + 1600 Ampitheatre Parkway + Mountain View, CA 94043, USA + + Phone: +1 650 623 6925 + EMail: robsiemb@google.com + + + Alexey Melnikov + Isode Limited + 5 Castle Business Village, 36 Station Road, + Hampton, Middlesex, TW12 2BX, UK + + EMail: Alexey.Melnikov@isode.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Siemborski & Melnikov Standards Track [Page 19] + +RFC 4954 SMTP Service Extension for Authentication July 2007 + + +Full Copyright Statement + + 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. + + + + + + + +Siemborski & Melnikov Standards Track [Page 20] + -- cgit v1.2.3