]>
Commit | Line | Data |
---|---|---|
ef416fc2 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group J. Myers | |
8 | Request for Comments: 2554 Netscape Communications | |
9 | Category: Standards Track March 1999 | |
10 | ||
11 | ||
12 | SMTP Service Extension | |
13 | for Authentication | |
14 | ||
15 | Status of this Memo | |
16 | ||
17 | This document specifies an Internet standards track protocol for the | |
18 | Internet community, and requests discussion and suggestions for | |
19 | improvements. Please refer to the current edition of the "Internet | |
20 | Official Protocol Standards" (STD 1) for the standardization state | |
21 | and status of this protocol. Distribution of this memo is unlimited. | |
22 | ||
23 | Copyright Notice | |
24 | ||
25 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
26 | ||
27 | ||
28 | 1. Introduction | |
29 | ||
30 | This document defines an SMTP service extension [ESMTP] whereby an | |
31 | SMTP client may indicate an authentication mechanism to the server, | |
32 | perform an authentication protocol exchange, and optionally negotiate | |
33 | a security layer for subsequent protocol interactions. This | |
34 | extension is a profile of the Simple Authentication and Security | |
35 | Layer [SASL]. | |
36 | ||
37 | ||
38 | 2. Conventions Used in this Document | |
39 | ||
40 | In examples, "C:" and "S:" indicate lines sent by the client and | |
41 | server respectively. | |
42 | ||
43 | The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" | |
44 | in this document are to be interpreted as defined in "Key words for | |
45 | use in RFCs to Indicate Requirement Levels" [KEYWORDS]. | |
46 | ||
47 | ||
48 | 3. The Authentication service extension | |
49 | ||
50 | ||
51 | (1) the name of the SMTP service extension is "Authentication" | |
52 | ||
53 | (2) the EHLO keyword value associated with this extension is "AUTH" | |
54 | ||
55 | ||
56 | ||
57 | ||
58 | Myers Standards Track [Page 1] | |
59 | \f | |
60 | RFC 2554 SMTP Authentication March 1999 | |
61 | ||
62 | ||
63 | (3) The AUTH EHLO keyword contains as a parameter a space separated | |
64 | list of the names of supported SASL mechanisms. | |
65 | ||
66 | (4) a new SMTP verb "AUTH" is defined | |
67 | ||
68 | (5) an optional parameter using the keyword "AUTH" is added to the | |
69 | MAIL FROM command, and extends the maximum line length of the | |
70 | MAIL FROM command by 500 characters. | |
71 | ||
72 | (6) this extension is appropriate for the submission protocol | |
73 | [SUBMIT]. | |
74 | ||
75 | ||
76 | 4. The AUTH command | |
77 | ||
78 | AUTH mechanism [initial-response] | |
79 | ||
80 | Arguments: | |
81 | a string identifying a SASL authentication mechanism. | |
82 | an optional base64-encoded response | |
83 | ||
84 | Restrictions: | |
85 | After an AUTH command has successfully completed, no more AUTH | |
86 | commands may be issued in the same session. After a successful | |
87 | AUTH command completes, a server MUST reject any further AUTH | |
88 | commands with a 503 reply. | |
89 | ||
90 | The AUTH command is not permitted during a mail transaction. | |
91 | ||
92 | Discussion: | |
93 | The AUTH command indicates an authentication mechanism to the | |
94 | server. If the server supports the requested authentication | |
95 | mechanism, it performs an authentication protocol exchange to | |
96 | authenticate and identify the user. Optionally, it also | |
97 | negotiates a security layer for subsequent protocol | |
98 | interactions. If the requested authentication mechanism is not | |
99 | supported, the server rejects the AUTH command with a 504 | |
100 | reply. | |
101 | ||
102 | The authentication protocol exchange consists of a series of | |
103 | server challenges and client answers that are specific to the | |
104 | authentication mechanism. A server challenge, otherwise known | |
105 | as a ready response, is a 334 reply with the text part | |
106 | containing a BASE64 encoded string. The client answer consists | |
107 | of a line containing a BASE64 encoded string. If the client | |
108 | wishes to cancel an authentication exchange, it issues a line | |
109 | with a single "*". If the server receives such an answer, it | |
110 | MUST reject the AUTH command by sending a 501 reply. | |
111 | ||
112 | ||
113 | ||
114 | Myers Standards Track [Page 2] | |
115 | \f | |
116 | RFC 2554 SMTP Authentication March 1999 | |
117 | ||
118 | ||
119 | The optional initial-response argument to the AUTH command is | |
120 | used to save a round trip when using authentication mechanisms | |
121 | that are defined to send no data in the initial challenge. | |
122 | When the initial-response argument is used with such a | |
123 | mechanism, the initial empty challenge is not sent to the | |
124 | client and the server uses the data in the initial-response | |
125 | argument as if it were sent in response to the empty challenge. | |
126 | Unlike a zero-length client answer to a 334 reply, a zero- | |
127 | length initial response is sent as a single equals sign ("="). | |
128 | If the client uses an initial-response argument to the AUTH | |
129 | command with a mechanism that sends data in the initial | |
130 | challenge, the server rejects the AUTH command with a 535 | |
131 | reply. | |
132 | ||
133 | If the server cannot BASE64 decode the argument, it rejects the | |
134 | AUTH command with a 501 reply. If the server rejects the | |
135 | authentication data, it SHOULD reject the AUTH command with a | |
136 | 535 reply unless a more specific error code, such as one listed | |
137 | in section 6, is appropriate. Should the client successfully | |
138 | complete the authentication exchange, the SMTP server issues a | |
139 | 235 reply. | |
140 | ||
141 | The service name specified by this protocol's profile of SASL | |
142 | is "smtp". | |
143 | ||
144 | If a security layer is negotiated through the SASL | |
145 | authentication exchange, it takes effect immediately following | |
146 | the CRLF that concludes the authentication exchange for the | |
147 | client, and the CRLF of the success reply for the server. Upon | |
148 | a security layer's taking effect, the SMTP protocol is reset to | |
149 | the initial state (the state in SMTP after a server issues a | |
150 | 220 service ready greeting). The server MUST discard any | |
151 | knowledge obtained from the client, such as the argument to the | |
152 | EHLO command, which was not obtained from the SASL negotiation | |
153 | itself. The client MUST discard any knowledge obtained from | |
154 | the server, such as the list of SMTP service extensions, which | |
155 | was not obtained from the SASL negotiation itself (with the | |
156 | exception that a client MAY compare the list of advertised SASL | |
157 | mechanisms before and after authentication in order to detect | |
158 | an active down-negotiation attack). The client SHOULD send an | |
159 | EHLO command as the first command after a successful SASL | |
160 | negotiation which results in the enabling of a security layer. | |
161 | ||
162 | The server is not required to support any particular | |
163 | authentication mechanism, nor are authentication mechanisms | |
164 | required to support any security layers. If an AUTH command | |
165 | fails, the client may try another authentication mechanism by | |
166 | issuing another AUTH command. | |
167 | ||
168 | ||
169 | ||
170 | Myers Standards Track [Page 3] | |
171 | \f | |
172 | RFC 2554 SMTP Authentication March 1999 | |
173 | ||
174 | ||
175 | If an AUTH command fails, the server MUST behave the same as if | |
176 | the client had not issued the AUTH command. | |
177 | ||
178 | The BASE64 string may in general be arbitrarily long. Clients | |
179 | and servers MUST be able to support challenges and responses | |
180 | that are as long as are generated by the authentication | |
181 | mechanisms they support, independent of any line length | |
182 | limitations the client or server may have in other parts of its | |
183 | protocol implementation. | |
184 | ||
185 | Examples: | |
186 | S: 220 smtp.example.com ESMTP server ready | |
187 | C: EHLO jgm.example.com | |
188 | S: 250-smtp.example.com | |
189 | S: 250 AUTH CRAM-MD5 DIGEST-MD5 | |
190 | C: AUTH FOOBAR | |
191 | S: 504 Unrecognized authentication type. | |
192 | C: AUTH CRAM-MD5 | |
193 | S: 334 | |
194 | PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4= | |
195 | C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== | |
196 | S: 235 Authentication successful. | |
197 | ||
198 | ||
199 | ||
200 | 5. The AUTH parameter to the MAIL FROM command | |
201 | ||
202 | AUTH=addr-spec | |
203 | ||
204 | Arguments: | |
205 | An addr-spec containing the identity which submitted the message | |
206 | to the delivery system, or the two character sequence "<>" | |
207 | indicating such an identity is unknown or insufficiently | |
208 | authenticated. To comply with the restrictions imposed on ESMTP | |
209 | parameters, the addr-spec is encoded inside an xtext. The syntax | |
210 | of an xtext is described in section 5 of [ESMTP-DSN]. | |
211 | ||
212 | Discussion: | |
213 | The optional AUTH parameter to the MAIL FROM command allows | |
214 | cooperating agents in a trusted environment to communicate the | |
215 | authentication of individual messages. | |
216 | ||
217 | If the server trusts the authenticated identity of the client to | |
218 | assert that the message was originally submitted by the supplied | |
219 | addr-spec, then the server SHOULD supply the same addr-spec in an | |
220 | AUTH parameter when relaying the message to any server which | |
221 | supports the AUTH extension. | |
222 | ||
223 | ||
224 | ||
225 | ||
226 | Myers Standards Track [Page 4] | |
227 | \f | |
228 | RFC 2554 SMTP Authentication March 1999 | |
229 | ||
230 | ||
231 | A MAIL FROM parameter of AUTH=<> indicates that the original | |
232 | submitter of the message is not known. The server MUST NOT treat | |
233 | the message as having been originally submitted by the client. | |
234 | ||
235 | If the AUTH parameter to the MAIL FROM is not supplied, the | |
236 | client has authenticated, and the server believes the message is | |
237 | an original submission by the client, the server MAY supply the | |
238 | client's identity in the addr-spec in an AUTH parameter when | |
239 | relaying the message to any server which supports the AUTH | |
240 | extension. | |
241 | ||
242 | If the server does not sufficiently trust the authenticated | |
243 | identity of the client, or if the client is not authenticated, | |
244 | then the server MUST behave as if the AUTH=<> parameter was | |
245 | supplied. The server MAY, however, write the value of the AUTH | |
246 | parameter to a log file. | |
247 | ||
248 | If an AUTH=<> parameter was supplied, either explicitly or due to | |
249 | the requirement in the previous paragraph, then the server MUST | |
250 | supply the AUTH=<> parameter when relaying the message to any | |
251 | server which it has authenticated to using the AUTH extension. | |
252 | ||
253 | A server MAY treat expansion of a mailing list as a new | |
254 | submission, setting the AUTH parameter to the mailing list | |
255 | address or mailing list administration address when relaying the | |
256 | message to list subscribers. | |
257 | ||
258 | It is conforming for an implementation to be hard-coded to treat | |
259 | all clients as being insufficiently trusted. In that case, the | |
260 | implementation does nothing more than parse and discard | |
261 | syntactically valid AUTH parameters to the MAIL FROM command and | |
262 | supply AUTH=<> parameters to any servers to which it | |
263 | authenticates using the AUTH extension. | |
264 | ||
265 | Examples: | |
266 | C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com | |
267 | S: 250 OK | |
268 | ||
269 | ||
270 | ||
271 | ||
272 | ||
273 | ||
274 | ||
275 | ||
276 | ||
277 | ||
278 | ||
279 | ||
280 | ||
281 | ||
282 | Myers Standards Track [Page 5] | |
283 | \f | |
284 | RFC 2554 SMTP Authentication March 1999 | |
285 | ||
286 | ||
287 | 6. Error Codes | |
288 | ||
289 | The following error codes may be used to indicate various conditions | |
290 | as described. | |
291 | ||
292 | 432 A password transition is needed | |
293 | ||
294 | This response to the AUTH command indicates that the user needs to | |
295 | transition to the selected authentication mechanism. This typically | |
296 | done by authenticating once using the PLAIN authentication mechanism. | |
297 | ||
298 | 534 Authentication mechanism is too weak | |
299 | ||
300 | This response to the AUTH command indicates that the selected | |
301 | authentication mechanism is weaker than server policy permits for | |
302 | that user. | |
303 | ||
304 | 538 Encryption required for requested authentication mechanism | |
305 | ||
306 | This response to the AUTH command indicates that the selected | |
307 | authentication mechanism may only be used when the underlying SMTP | |
308 | connection is encrypted. | |
309 | ||
310 | 454 Temporary authentication failure | |
311 | ||
312 | This response to the AUTH command indicates that the authentication | |
313 | failed due to a temporary server failure. | |
314 | ||
315 | 530 Authentication required | |
316 | ||
317 | This response may be returned by any command other than AUTH, EHLO, | |
318 | HELO, NOOP, RSET, or QUIT. It indicates that server policy requires | |
319 | authentication in order to perform the requested action. | |
320 | ||
321 | ||
322 | ||
323 | ||
324 | ||
325 | ||
326 | ||
327 | ||
328 | ||
329 | ||
330 | ||
331 | ||
332 | ||
333 | ||
334 | ||
335 | ||
336 | ||
337 | ||
338 | Myers Standards Track [Page 6] | |
339 | \f | |
340 | RFC 2554 SMTP Authentication March 1999 | |
341 | ||
342 | ||
343 | 7. Formal Syntax | |
344 | ||
345 | The following syntax specification uses the augmented Backus-Naur | |
346 | Form (BNF) notation as specified in [ABNF]. | |
347 | ||
348 | Except as noted otherwise, all alphabetic characters are case- | |
349 | insensitive. The use of upper or lower case characters to define | |
350 | token strings is for editorial clarity only. Implementations MUST | |
351 | accept these strings in a case-insensitive fashion. | |
352 | ||
353 | UPALPHA = %x41-5A ;; Uppercase: A-Z | |
354 | ||
355 | LOALPHA = %x61-7A ;; Lowercase: a-z | |
356 | ||
357 | ALPHA = UPALPHA / LOALPHA ;; case insensitive | |
358 | ||
359 | DIGIT = %x30-39 ;; Digits 0-9 | |
360 | ||
361 | HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase) | |
362 | ||
363 | hexchar = "+" HEXDIGIT HEXDIGIT | |
364 | ||
365 | xchar = %x21-2A / %x2C-3C / %x3E-7E | |
366 | ;; US-ASCII except for "+", "=", SPACE and CTL | |
367 | ||
368 | xtext = *(xchar / hexchar) | |
369 | ||
370 | AUTH_CHAR = ALPHA / DIGIT / "-" / "_" | |
371 | ||
372 | auth_type = 1*20AUTH_CHAR | |
373 | ||
374 | auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")] | |
375 | *(CRLF [base64]) CRLF | |
376 | ||
377 | auth_param = "AUTH=" xtext | |
378 | ;; The decoded form of the xtext MUST be either | |
379 | ;; an addr-spec or the two characters "<>" | |
380 | ||
381 | base64 = base64_terminal / | |
382 | ( 1*(4base64_CHAR) [base64_terminal] ) | |
383 | ||
384 | base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" | |
385 | ;; Case-sensitive | |
386 | ||
387 | base64_terminal = (2base64_char "==") / (3base64_char "=") | |
388 | ||
389 | continue_req = "334" SPACE [base64] CRLF | |
390 | ||
391 | ||
392 | ||
393 | ||
394 | Myers Standards Track [Page 7] | |
395 | \f | |
396 | RFC 2554 SMTP Authentication March 1999 | |
397 | ||
398 | ||
399 | CR = %x0C ;; ASCII CR, carriage return | |
400 | ||
401 | CRLF = CR LF | |
402 | ||
403 | CTL = %x00-1F / %x7F ;; any ASCII control character and DEL | |
404 | ||
405 | LF = %x0A ;; ASCII LF, line feed | |
406 | ||
407 | SPACE = %x20 ;; ASCII SP, space | |
408 | ||
409 | ||
410 | ||
411 | ||
412 | 8. References | |
413 | ||
414 | [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |
415 | Specifications: ABNF", RFC 2234, November 1997. | |
416 | ||
417 | [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP | |
418 | AUTHorize Extension for Simple Challenge/Response", RFC | |
419 | 2195, September 1997. | |
420 | ||
421 | [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. | |
422 | Crocker, "SMTP Service Extensions", RFC 1869, November | |
423 | 1995. | |
424 | ||
425 | [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status | |
426 | Notifications", RFC 1891, January 1996. | |
427 | ||
428 | [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | |
429 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
430 | ||
431 | [SASL] Myers, J., "Simple Authentication and Security Layer | |
432 | (SASL)", RFC 2222, October 1997. | |
433 | ||
434 | [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC | |
435 | 2476, December 1998. | |
436 | ||
437 | [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC | |
438 | 821, August 1982. | |
439 | ||
440 | [RFC822] Crocker, D., "Standard for the Format of ARPA Internet | |
441 | Text Messages", STD 11, RFC 822, August 1982. | |
442 | ||
443 | ||
444 | ||
445 | ||
446 | ||
447 | ||
448 | ||
449 | ||
450 | Myers Standards Track [Page 8] | |
451 | \f | |
452 | RFC 2554 SMTP Authentication March 1999 | |
453 | ||
454 | ||
455 | 9. Security Considerations | |
456 | ||
457 | Security issues are discussed throughout this memo. | |
458 | ||
459 | If a client uses this extension to get an encrypted tunnel through an | |
460 | insecure network to a cooperating server, it needs to be configured | |
461 | to never send mail to that server when the connection is not mutually | |
462 | authenticated and encrypted. Otherwise, an attacker could steal the | |
463 | client's mail by hijacking the SMTP connection and either pretending | |
464 | the server does not support the Authentication extension or causing | |
465 | all AUTH commands to fail. | |
466 | ||
467 | Before the SASL negotiation has begun, any protocol interactions are | |
468 | performed in the clear and may be modified by an active attacker. | |
469 | For this reason, clients and servers MUST discard any knowledge | |
470 | obtained prior to the start of the SASL negotiation upon completion | |
471 | of a SASL negotiation which results in a security layer. | |
472 | ||
473 | This mechanism does not protect the TCP port, so an active attacker | |
474 | may redirect a relay connection attempt to the submission port | |
475 | [SUBMIT]. The AUTH=<> parameter prevents such an attack from causing | |
476 | an relayed message without an envelope authentication to pick up the | |
477 | authentication of the relay client. | |
478 | ||
479 | A message submission client may require the user to authenticate | |
480 | whenever a suitable SASL mechanism is advertised. Therefore, it may | |
481 | not be desirable for a submission server [SUBMIT] to advertise a SASL | |
482 | mechanism when use of that mechanism grants the client no benefits | |
483 | over anonymous submission. | |
484 | ||
485 | This extension is not intended to replace or be used instead of end- | |
486 | to-end message signature and encryption systems such as S/MIME or | |
487 | PGP. This extension addresses a different problem than end-to-end | |
488 | systems; it has the following key differences: | |
489 | ||
490 | (1) it is generally useful only within a trusted enclave | |
491 | ||
492 | (2) it protects the entire envelope of a message, not just the | |
493 | message's body. | |
494 | ||
495 | (3) it authenticates the message submission, not authorship of the | |
496 | message content | |
497 | ||
498 | (4) it can give the sender some assurance the message was | |
499 | delivered to the next hop in the case where the sender | |
500 | mutually authenticates with the next hop and negotiates an | |
501 | appropriate security layer. | |
502 | ||
503 | ||
504 | ||
505 | ||
506 | Myers Standards Track [Page 9] | |
507 | \f | |
508 | RFC 2554 SMTP Authentication March 1999 | |
509 | ||
510 | ||
511 | Additional security considerations are mentioned in the SASL | |
512 | specification [SASL]. | |
513 | ||
514 | ||
515 | ||
516 | 10. Author's Address | |
517 | ||
518 | John Gardiner Myers | |
519 | Netscape Communications | |
520 | 501 East Middlefield Road | |
521 | Mail Stop MV-029 | |
522 | Mountain View, CA 94043 | |
523 | ||
524 | EMail: jgmyers@netscape.com | |
525 | ||
526 | ||
527 | ||
528 | ||
529 | ||
530 | ||
531 | ||
532 | ||
533 | ||
534 | ||
535 | ||
536 | ||
537 | ||
538 | ||
539 | ||
540 | ||
541 | ||
542 | ||
543 | ||
544 | ||
545 | ||
546 | ||
547 | ||
548 | ||
549 | ||
550 | ||
551 | ||
552 | ||
553 | ||
554 | ||
555 | ||
556 | ||
557 | ||
558 | ||
559 | ||
560 | ||
561 | ||
562 | Myers Standards Track [Page 10] | |
563 | \f | |
564 | RFC 2554 SMTP Authentication March 1999 | |
565 | ||
566 | ||
567 | 11. Full Copyright Statement | |
568 | ||
569 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
570 | ||
571 | This document and translations of it may be copied and furnished to | |
572 | others, and derivative works that comment on or otherwise explain it | |
573 | or assist in its implementation may be prepared, copied, published | |
574 | and distributed, in whole or in part, without restriction of any | |
575 | kind, provided that the above copyright notice and this paragraph are | |
576 | included on all such copies and derivative works. However, this | |
577 | document itself may not be modified in any way, such as by removing | |
578 | the copyright notice or references to the Internet Society or other | |
579 | Internet organizations, except as needed for the purpose of | |
580 | developing Internet standards in which case the procedures for | |
581 | copyrights defined in the Internet Standards process must be | |
582 | followed, or as required to translate it into languages other than | |
583 | English. | |
584 | ||
585 | The limited permissions granted above are perpetual and will not be | |
586 | revoked by the Internet Society or its successors or assigns. | |
587 | ||
588 | This document and the information contained herein is provided on an | |
589 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
590 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
591 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
592 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
593 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
594 | ||
595 | ||
596 | ||
597 | ||
598 | ||
599 | ||
600 | ||
601 | ||
602 | ||
603 | ||
604 | ||
605 | ||
606 | ||
607 | ||
608 | ||
609 | ||
610 | ||
611 | ||
612 | ||
613 | ||
614 | ||
615 | ||
616 | ||
617 | ||
618 | Myers Standards Track [Page 11] | |
619 | \f |