idnits 2.17.1 draft-myers-smtp-auth-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1998) is 9560 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC821' is defined on line 294, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1869 (ref. 'ESMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1890 (ref. 'ESMTP-DSN') (Obsoleted by RFC 3551) -- Unexpected draft version: The latest known version of draft-myers-auth-sasl is -12, but you're referring to -13. ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Myers 3 Internet Draft: SMTP Authentication February 1998 4 Document: draft-myers-smtp-auth-11.txt 6 SMTP Service Extension 7 for Authentication 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 ``working draft'' or ``work in progress``. 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the RFC 27 editor as a Proposed Standard for the Internet Community. Discussion 28 and suggestions for improvement are requested. This document will 29 expire before July 1996. Distribution of this draft is unlimited. 31 1. Introduction 33 This document defines an SMTP service extension [ESMTP] whereby an 34 SMTP client may indicate an authentication mechanism to the server, 35 perform an authentication protocol exchange, and optionally negotiate 36 a security layer for subsequent protocol interactions. This 37 extension is a profile of the Simple Authentication and Security 38 Layer [SASL]. 40 2. Conventions Used in this Document 42 In examples, "C:" and "S:" indicate lines sent by the client and 43 server respectively. 45 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 46 in this document are to be interpreted as defined in "Key words for 47 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 49 3. The Authentication service extension 51 (1) the name of the SMTP service extension is "Authentication" 53 (2) the EHLO keyword value associated with this extension is "AUTH" 55 (3) The AUTH EHLO keyword contains as a parameter a space separated 56 list of the names of supported SASL mechanisms. 58 (4) a new SMTP verb "AUTH" is defined 60 (5) an optional parameter using the keyword "AUTH" is added to the 61 MAIL FROM command. 63 4. The AUTH command 65 AUTH mechanism [initial-response] 67 Arguments: 68 a string identifying a SASL authentication mechanism. 69 an optional base64-encoded response 71 Restrictions: 72 after an AUTH command has successfully completed, no more AUTH 73 commands may be issued in the same session. After a successful 74 AUTH command completes, a server MUST reject any further AUTH 75 commands with a 503 reply. 77 Discussion: 78 The AUTH command indicates an authentication mechanism to the 79 server. If the server supports the requested authentication 80 mechanism, it performs an authentication protocol exchange to 81 authenticate and identify the user. Optionally, it also 82 negotiates a security layer for subsequent protocol 83 interactions. If the requested authentication mechanism is not 84 supported, the server rejects the AUTH command with a 504 85 reply. 87 The authentication protocol exchange consists of a series of 88 server challenges and client answers that are specific to the 89 authentication mechanism. A server challenge, otherwise known 90 as a ready response, is a 334 reply with the text part 91 containing a BASE64 encoded string. The client answer consists 92 of a line containing a BASE64 encoded string. If the client 93 wishes to cancel an authentication exchange, it issues a line 94 with a single "*". If the server receives such an answer, it 95 MUST reject the AUTH command by sending a 501 reply. 97 The optional initial-response argument to the AUTH command is 98 used to save a round trip when using authentication mechanisms 99 that are defined to send no data in the initial challenge. 100 When the initial-response argument is used with such a 101 mechanism, the initial empty challenge is not sent to the 102 client and the server uses the data in the initial-response 103 argument as if it were sent in response to the empty challenge. 104 If the initial-response argument to the AUTH command is used 105 with a mechanism that sends data in the initial challenge, the 106 server rejects the AUTH command with a 535 reply. 108 If the server cannot BASE64 decode the argument, it rejects the 109 AUTH command with a 501 reply. If the server rejects the 110 authentication data, it SHOULD reject the AUTH command with a 111 535 reply unless a more specific error code, such as one listed 112 in section 6, is appropriate. Should the client successfully 113 complete the authentication exchange, the SMTP server issues a 114 235 reply. 116 The service name specified by this protocol's profile of SASL 117 is "smtp". 119 If a security layer is negotiated through the SASL 120 authentication exchange, it takes effect immediately following 121 the CRLF that concludes the authentication exchange for the 122 client, and the CRLF of the success reply for the server. 124 The server is not required to support any particular 125 authentication mechanism, nor are authentication mechanisms 126 required to support any security layers. If an AUTH command 127 fails, the client may try another authentication mechanism by 128 issuing another AUTH command. In other words, the client may 129 request authentication types in decreasing order of preference. 131 If an AUTH command fails, the server MUST behave the same as if 132 the client had not issued the AUTH command. 134 The BASE64 string may in general be arbitrarily long. Clients 135 and servers MUST be able to support challenges and responses 136 that are as long as are generated by the authentication 137 mechanisms they support, independent of any line length 138 limitations the client or server may have in other parts of its 139 protocol implementation. 141 Examples: 142 S: 220 smtp.andrew.cmu.edu ESMTP server ready 143 C: EHLO jgm.pc.cc.cmu.edu 144 S: 250-smtp.andrew.cmu.edu 145 S: 250 AUTH SKEY PLAIN 146 C: AUTH FOOBAR 147 S: 504 Unrecognized authentication type 148 C: AUTH SKEY c21pdGg= 149 S: 334 OTUgUWE1ODMwOA== 150 C: BsAY3g4gBNo= 151 S: 235 S/Key authentication successful 153 5. The AUTH parameter to the MAIL FROM command 155 AUTH=addr-spec 157 Arguments: 158 An addr-spec containing the identity which submitted the message 159 to the delivery system. To comply with the restrictions imposed 160 on ESMTP parameters, the addr-spec is encoded inside an xtext. 161 The syntax of an xtext is described in section 5 of [ESMTP-DSN]. 163 Discussion: 164 The optional AUTH parameter to the MAIL FROM command allows 165 cooperating agents in a trusted environment to communicate the 166 authentication of individual messages. 168 If the server trusts the authenticated identity of the client to 169 assert that the message was originally submitted by the supplied 170 addr-spec, then the server SHOULD supply the same addr-spec in an 171 AUTH parameter when relaying the message to any server which 172 supports the AUTH extension. 174 If the server does not sufficiently trust the authenticated 175 identity of the client, or if the client is not authenticated, 176 then the server MUST behave as if no AUTH parameter was supplied. 177 The server MAY, however, place the value of the AUTH parameter in 178 a comment in the inserted Received: header and/or write it to a 179 log file. 181 A server MAY treat expansion of a mailing list as a new 182 submission, setting the AUTH parameter to the mailing list 183 address or mailing list administration address when relaying the 184 message to list subscribers. 186 It is conforming for an implementation to be hard-coded to treat 187 all clients as being insufficiently trusted. In that case, the 188 implementation does nothing more than parse and discard 189 syntactically valid AUTH parameters to the MAIL FROM command. 191 6. Error Codes 193 The following error codes may be used to indicate various conditions 194 as described. 196 422 A password transition is needed 198 This response to the AUTH command indicates that the user needs to 199 transition to the selected authentication mechanism. This typically 200 done by authenticating once using the PLAIN authentication mechanism. 202 522 Authentication mechanism is too weak 204 This response to the AUTH command indicates that the selected 205 authentication mechanism is weaker than server policy permits for 206 that user. 208 523 Encryption required for requested authentication mechanism 210 This response to the AUTH command indicates that the selected 211 authentication mechanism may only be used when the underlying SMTP 212 connection is encrypted. 214 454 Temporary authentication failure 216 This response to the AUTH command indicates that the authentication 217 failed due to a temporary server failure. 219 505 Authentication required 221 This response may be returned by any command other than AUTH, EHLO, 222 NOOP, or QUIT. It indicates that server policy requires 223 authentication in order to perform the requested action. 225 7. Formal Syntax 227 The following syntax specification uses the augmented Backus-Naur 228 Form (BNF) notation as specified in [RFC822]. 230 Except as noted otherwise, all alphabetic characters are case- 231 insensitive. The use of upper or lower case characters to define 232 token strings is for editorial clarity only. Implementations MUST 233 accept these strings in a case-insensitive fashion. 235 ATOM_CHAR = 237 atom_specials = "(" / ")" / "{" / SPACE / CTLs / "%" / "*" / 238 <"> / "\" 240 auth_command = "AUTH" SPACE auth_type [SPACE base64] 241 *(CRLF base64) CRLF 243 auth_param = "AUTH=" xtext 244 ;; xtext is defined in section 5 of RFC 1891 245 ;; The decoded form of the xtext MUST be an addr-spec 247 auth_type = 1*ATOM_CHAR 249 base64 = *(4base64_CHAR) [base64_terminal] 251 base64_char = "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / 252 "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / 253 "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / 254 "Y" / "Z" / 255 "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / 256 "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / 257 "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / 258 "y" / "z" / 259 "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / 260 "8" / "9" / "+" / "/" 261 ;; Case-sensitive 263 base64_terminal = (2base64_char "==") / (3base64_char "=") 265 CHAR = 268 continue_req = "334" SPACE base64 CRLF 270 CR = 272 CRLF = CR LF 273 CTL = 276 LF = 278 SPACE = 280 8. References 282 [ESMTP] Klensin et al, "SMTP Service Extensions", RFC 1869, November 283 1995. 285 [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status 286 Notifications", RFC 1890. 288 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 289 Requirement Levels", RFC 2119, March 1997. 291 [SASL] Myers, J., "Simple Authentication and Security Layer", 292 draft-myers-auth-sasl-13.txt, November 1997. 294 [RFC821] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 295 1982. 297 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 298 Messages", RFC 822, August 1982. 300 9. Security Considerations 302 Security issues are discussed throughout this memo. 304 If a client uses this extension to get an encrypted tunnel through an 305 insecure network to a cooperating server, it needs to be configured 306 to never send mail to that server when the connection is not mutually 307 authenticated and encrypted. Otherwise, an attacker could steal the 308 client's mail by hijacking the SMTP connection and either pretending 309 the server does not support the Authentication extension or causing 310 all AUTH commands to fail. 312 This extension does not provide a defined mechanism for 313 authentication using a plaintext password. This omission is 314 intentional. 316 This extension is not intended to replace or be used instead of end- 317 to-end message signature and encryption systems such as PEM or PGP. 318 This extension addresses a different problem than end-to-end systems; 319 it has the following key differences: 321 (1) it is generally useful only within a trusted enclave 323 (2) it protects the entire envelope of a message, not just the 324 message's body. 326 (3) it authenticates the message submission, not authorship of the 327 message content 329 (4) it can give the sender some assurance the message was delivered 330 to the next hop in the case where the sender mutually 331 authenticates with the next hop and negotiates an appropriate 332 security layer. 334 Additional security considerations are mentioned in the SASL 335 specification [SASL]. 337 10. Author's Address: 339 John Gardiner Myers 340 Netscape Communications 341 501 East Middlefield Road 342 Mail Stop MV-029 343 Mountain View, CA 94043 345 Email: jgmyers@netscape.com