idnits 2.17.1 draft-myers-smtp-auth-12.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-26) 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 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 are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (November 1998) is 9294 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: 'CRAM-MD5' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'RFC821' is defined on line 351, but no explicit reference was found in the text == Unused Reference: 'RFC822' is defined on line 354, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1869 (ref. 'ESMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1891 (ref. 'ESMTP-DSN') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) -- Unexpected draft version: The latest known version of draft-gellens-submit 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: 15 errors (**), 0 flaws (~~), 5 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 November 1998 4 Document: draft-myers-smtp-auth-12.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 months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 23 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 24 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 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 in six months. 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, and extends the maximum line length of the 62 MAIL FROM command by 500 characters. 64 (6) this extension is appropriate for the submission protocol 65 [SUBMIT]. 67 4. The AUTH command 69 AUTH mechanism [initial-response] 71 Arguments: 72 a string identifying a SASL authentication mechanism. 73 an optional base64-encoded response 75 Restrictions: 76 After an AUTH command has successfully completed, no more AUTH 77 commands may be issued in the same session. After a successful 78 AUTH command completes, a server MUST reject any further AUTH 79 commands with a 503 reply. 81 The AUTH command is not permitted during a mail transaction. 83 Discussion: 84 The AUTH command indicates an authentication mechanism to the 85 server. If the server supports the requested authentication 86 mechanism, it performs an authentication protocol exchange to 87 authenticate and identify the user. Optionally, it also 88 negotiates a security layer for subsequent protocol 89 interactions. If the requested authentication mechanism is not 90 supported, the server rejects the AUTH command with a 504 91 reply. 93 The authentication protocol exchange consists of a series of 94 server challenges and client answers that are specific to the 95 authentication mechanism. A server challenge, otherwise known 96 as a ready response, is a 334 reply with the text part 97 containing a BASE64 encoded string. The client answer consists 98 of a line containing a BASE64 encoded string. If the client 99 wishes to cancel an authentication exchange, it issues a line 100 with a single "*". If the server receives such an answer, it 101 MUST reject the AUTH command by sending a 501 reply. 103 The optional initial-response argument to the AUTH command is 104 used to save a round trip when using authentication mechanisms 105 that are defined to send no data in the initial challenge. 106 When the initial-response argument is used with such a 107 mechanism, the initial empty challenge is not sent to the 108 client and the server uses the data in the initial-response 109 argument as if it were sent in response to the empty challenge. 110 Unlike a zero-length client answer to a 334 reply, a zero- 111 length initial response is sent as a single equals sign ("="). 112 If the client uses an initial-response argument to the AUTH 113 command with a mechanism that sends data in the initial 114 challenge, the server rejects the AUTH command with a 535 115 reply. 117 If the server cannot BASE64 decode the argument, it rejects the 118 AUTH command with a 501 reply. If the server rejects the 119 authentication data, it SHOULD reject the AUTH command with a 120 535 reply unless a more specific error code, such as one listed 121 in section 6, is appropriate. Should the client successfully 122 complete the authentication exchange, the SMTP server issues a 123 235 reply. 125 The service name specified by this protocol's profile of SASL 126 is "smtp". 128 If a security layer is negotiated through the SASL 129 authentication exchange, it takes effect immediately following 130 the CRLF that concludes the authentication exchange for the 131 client, and the CRLF of the success reply for the server. Upon 132 a security layer's taking effect, the SMTP protocol is reset to 133 the initial state (the state in SMTP after a server issues a 134 220 service ready greeting). The server MUST discard any 135 knowledge obtained from the client, such as the argument to the 136 EHLO command, which was not obtained from the SASL negotiation 137 itself. The client MUST discard any knowledge obtained from 138 the server, such as the list of SMTP service extensions, which 139 was not obtained from the SASL negotiation itself (with the 140 exception that a client MAY compare the list of advertised SASL 141 mechanisms before and after authentication in order to detect 142 an active down-negotiation attack). The client SHOULD send an 143 EHLO command as the first command after a successful SASL 144 negotiation which results in the enabling of a security layer. 146 The server is not required to support any particular 147 authentication mechanism, nor are authentication mechanisms 148 required to support any security layers. If an AUTH command 149 fails, the client may try another authentication mechanism by 150 issuing another AUTH command. 152 If an AUTH command fails, the server MUST behave the same as if 153 the client had not issued the AUTH command. 155 The BASE64 string may in general be arbitrarily long. Clients 156 and servers MUST be able to support challenges and responses 157 that are as long as are generated by the authentication 158 mechanisms they support, independent of any line length 159 limitations the client or server may have in other parts of its 160 protocol implementation. 162 Examples: 163 S: 220 smtp.example.com ESMTP server ready 164 C: EHLO jgm.example.com 165 S: 250-smtp.example.com 166 S: 250 AUTH CRAM-MD5 DIGEST-MD5 167 C: AUTH FOOBAR 168 S: 504 Unrecognized authentication type. 169 C: AUTH CRAM-MD5 170 S: 334 171 PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4= 172 C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== 173 S: 235 Authentication successful. 175 5. The AUTH parameter to the MAIL FROM command 177 AUTH=addr-spec 179 Arguments: 180 An addr-spec containing the identity which submitted the message 181 to the delivery system, or the two character sequence "<>" 182 indicating such an identity is unknown or insufficiently 183 authenticated. To comply with the restrictions imposed on ESMTP 184 parameters, the addr-spec is encoded inside an xtext. The syntax 185 of an xtext is described in section 5 of [ESMTP-DSN]. 187 Discussion: 188 The optional AUTH parameter to the MAIL FROM command allows 189 cooperating agents in a trusted environment to communicate the 190 authentication of individual messages. 192 If the server trusts the authenticated identity of the client to 193 assert that the message was originally submitted by the supplied 194 addr-spec, then the server SHOULD supply the same addr-spec in an 195 AUTH parameter when relaying the message to any server which 196 supports the AUTH extension. 198 A MAIL FROM parameter of AUTH=<> indicates that the original 199 submitter of the message is not known. The server MUST NOT treat 200 the message as having been originally submitted by the client. 202 If the AUTH parameter to the MAIL FROM is not supplied, the 203 client has authenticated, and the server believes the message is 204 an original submission by the client, the server MAY supply the 205 client's identity in the addr-spec in an AUTH parameter when 206 relaying the message to any server which supports the AUTH 207 extension. 209 If the server does not sufficiently trust the authenticated 210 identity of the client, or if the client is not authenticated, 211 then the server MUST behave as if the AUTH=<> parameter was 212 supplied. The server MAY, however, write the value of the AUTH 213 parameter to a log file. 215 If an AUTH=<> parameter was supplied, either explicitly or due to 216 the requirement in the previous paragraph, then the server MUST 217 supply the AUTH=<> parameter when relaying the message to any 218 server which it has authenticated to using the AUTH extension. 220 A server MAY treat expansion of a mailing list as a new 221 submission, setting the AUTH parameter to the mailing list 222 address or mailing list administration address when relaying the 223 message to list subscribers. 225 It is conforming for an implementation to be hard-coded to treat 226 all clients as being insufficiently trusted. In that case, the 227 implementation does nothing more than parse and discard 228 syntactically valid AUTH parameters to the MAIL FROM command and 229 supply AUTH=<> parameters to any servers to which it 230 authenticates using the AUTH extension. 232 Examples: 233 C: MAIL FROM: AUTH=e+3Dmc2@example.com 234 S: 250 OK 236 6. Error Codes 238 The following error codes may be used to indicate various conditions 239 as described. 241 432 A password transition is needed 243 This response to the AUTH command indicates that the user needs to 244 transition to the selected authentication mechanism. This typically 245 done by authenticating once using the PLAIN authentication mechanism. 247 534 Authentication mechanism is too weak 249 This response to the AUTH command indicates that the selected 250 authentication mechanism is weaker than server policy permits for 251 that user. 253 538 Encryption required for requested authentication mechanism 255 This response to the AUTH command indicates that the selected 256 authentication mechanism may only be used when the underlying SMTP 257 connection is encrypted. 259 454 Temporary authentication failure 261 This response to the AUTH command indicates that the authentication 262 failed due to a temporary server failure. 264 530 Authentication required 266 This response may be returned by any command other than AUTH, EHLO, 267 HELO, NOOP, RSET, or QUIT. It indicates that server policy requires 268 authentication in order to perform the requested action. 270 7. Formal Syntax 272 The following syntax specification uses the augmented Backus-Naur 273 Form (BNF) notation as specified in [ABNF]. 275 Except as noted otherwise, all alphabetic characters are case- 276 insensitive. The use of upper or lower case characters to define 277 token strings is for editorial clarity only. Implementations MUST 278 accept these strings in a case-insensitive fashion. 280 UPALPHA = %x41-5A ;; Uppercase: A-Z 282 LOALPHA = %x61-7A ;; Lowercase: a-z 284 ALPHA = UPALPHA / LOALPHA ;; case insensitive 286 DIGIT = %x30-39 ;; Digits 0-9 288 HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase) 290 hexchar = "+" HEXDIGIT HEXDIGIT 292 xchar = %x21-2A / %x2C-3C / %x3E-7E 293 ;; US-ASCII except for "+", "=", SPACE and CTL 295 xtext = *(xchar / hexchar) 297 AUTH_CHAR = ALPHA / DIGIT / "-" / "_" 299 auth_type = 1*20AUTH_CHAR 301 auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")] 302 *(CRLF [base64]) CRLF 304 auth_param = "AUTH=" xtext 305 ;; The decoded form of the xtext MUST be either 306 ;; an addr-spec or the two characters "<>" 308 base64 = base64_terminal / 309 ( 1*(4base64_CHAR) [base64_terminal] ) 311 base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" 312 ;; Case-sensitive 314 base64_terminal = (2base64_char "==") / (3base64_char "=") 316 continue_req = "334" SPACE [base64] CRLF 317 CR = %x0C ;; ASCII CR, carriage return 319 CRLF = CR LF 321 CTL = %x00-1F / %x7F ;; any ASCII control character and DEL 323 LF = %x0A ;; ASCII LF, line feed 325 SPACE = %x20 ;; ASCII SP, space 327 8. References 329 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 330 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 331 November 1997. 333 [CRAM-MD5] Klensin, J. et al, "IMAP/POP AUTHorize Extension for Simple 334 Challenge/Response", RFC 2195, September 1997. 336 [ESMTP] Klensin et al, "SMTP Service Extensions", RFC 1869, November 337 1995. 339 [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status 340 Notifications", RFC 1891. 342 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 343 Requirement Levels", RFC 2119, March 1997. 345 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", 346 RFC 2222, Netscape Communications, October 1997. 348 [SUBMIT] Gellens, R., Klensin, J., "Message Submission", 349 draft-gellens-submit-13.txt, October 1998 351 [RFC821] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 352 1982. 354 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 355 Messages", RFC 822, August 1982. 357 9. Security Considerations 359 Security issues are discussed throughout this memo. 361 If a client uses this extension to get an encrypted tunnel through an 362 insecure network to a cooperating server, it needs to be configured 363 to never send mail to that server when the connection is not mutually 364 authenticated and encrypted. Otherwise, an attacker could steal the 365 client's mail by hijacking the SMTP connection and either pretending 366 the server does not support the Authentication extension or causing 367 all AUTH commands to fail. 369 Before the SASL negotiation has begun, any protocol interactions are 370 performed in the clear and may be modified by an active attacker. 371 For this reason, clients and servers MUST discard any knowledge 372 obtained prior to the start of the SASL negotiation upon completion 373 of a SASL negotiation which results in a security layer. 375 This mechanism does not protect the TCP port, so an active attacker 376 may redirect a relay connection attempt to the submission port 377 [SUBMIT]. The AUTH=<> parameter prevents such an attack from causing 378 an relayed message without an envelope authentication to pick up the 379 authentication of the relay client. 381 A message submission client may require the user to authenticate 382 whenever a suitable SASL mechanism is advertised. Therefore, it may 383 not be desirable for a submission server [SUBMIT] to advertise a SASL 384 mechanism when use of that mechanism grants the client no benefits 385 over anonymous submission. 387 This extension is not intended to replace or be used instead of end- 388 to-end message signature and encryption systems such as S/MIME or 389 PGP. This extension addresses a different problem than end-to-end 390 systems; it has the following key differences: 392 (1) it is generally useful only within a trusted enclave 394 (2) it protects the entire envelope of a message, not just the 395 message's body. 397 (3) it authenticates the message submission, not authorship of the 398 message content 400 (4) it can give the sender some assurance the message was 401 delivered to the next hop in the case where the sender 402 mutually authenticates with the next hop and negotiates an 403 appropriate security layer. 405 Additional security considerations are mentioned in the SASL 406 specification [SASL]. 408 10. Author's Address: 410 John Gardiner Myers 411 Netscape Communications 412 501 East Middlefield Road 413 Mail Stop MV-029 414 Mountain View, CA 94043 416 Email: jgmyers@netscape.com