rfcs/rfc4954.txt -rw-r--r-- 42.5 KiB
1
2
3
4
5
6
7Network Working Group R. Siemborski, Ed.
8Request for Comments: 4954 Google, Inc.
9Obsoletes: 2554 A. Melnikov, Ed.
10Updates: 3463 Isode Limited
11Category: Standards Track July 2007
12
13
14 SMTP Service Extension for Authentication
15
16Status of This Memo
17
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
23
24Copyright Notice
25
26 Copyright (C) The IETF Trust (2007).
27
28Abstract
29
30 This document defines a Simple Mail Transport Protocol (SMTP)
31 extension whereby an SMTP client may indicate an authentication
32 mechanism to the server, perform an authentication protocol exchange,
33 and optionally negotiate a security layer for subsequent protocol
34 interactions during this session. This extension includes a profile
35 of the Simple Authentication and Security Layer (SASL) for SMTP.
36
37 This document obsoletes RFC 2554.
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58Siemborski & Melnikov Standards Track [Page 1]
59
60RFC 4954 SMTP Service Extension for Authentication July 2007
61
62
63Table of Contents
64
65 1. Introduction ....................................................2
66 2. How to Read This Document .......................................2
67 3. The Authentication Service Extension ............................3
68 4. The AUTH Command ................................................3
69 4.1. Examples ...................................................7
70 5. The AUTH Parameter to the MAIL FROM command .....................9
71 5.1. Examples ..................................................10
72 6. Status Codes ...................................................11
73 7. Additional requirements on servers .............................12
74 8. Formal Syntax ..................................................13
75 9. Security Considerations ........................................14
76 10. IANA Considerations ...........................................15
77 11. Normative References ..........................................15
78 12. Informative References ........................................16
79 13. Acknowledgments ...............................................17
80 14. Additional Requirements When Using SASL PLAIN over TLS ........17
81 15. Changes since RFC 2554 ........................................18
82
831. Introduction
84
85 This document defines a Simple Mail Transport Protocol (SMTP)
86 extension whereby an SMTP client may indicate an authentication
87 mechanism to the server, perform an authentication protocol exchange,
88 optionally negotiate a security layer for subsequent protocol
89 interactions during this session and, during a mail transaction,
90 optionally specify a mailbox associated with the identity that
91 submitted the message to the mail delivery system.
92
93 This extension includes a profile of the Simple Authentication and
94 Security Layer (SASL) for SMTP.
95
96 When compared to RFC 2554, this document deprecates use of the 538
97 response code, adds a new Enhanced Status Code, adds a requirement to
98 support SASLprep profile for preparing authorization identities,
99 recommends use of RFC 3848 transmission types in the Received trace
100 header field, and clarifies interaction with SMTP PIPELINING
101 [PIPELINING] extension.
102
1032. How to Read This Document
104
105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
107 document are to be interpreted as described in [KEYWORDS].
108
109 In examples, "C:" and "S:" indicate lines sent by the client and
110 server, respectively.
111
112
113
114Siemborski & Melnikov Standards Track [Page 2]
115
116RFC 4954 SMTP Service Extension for Authentication July 2007
117
118
1193. The Authentication Service Extension
120
121 1. The name of this [SMTP] service extension is "Authentication".
122
123 2. The EHLO keyword value associated with this extension is "AUTH".
124
125 3. The AUTH EHLO keyword contains as a parameter a space-separated
126 list of the names of available [SASL] mechanisms. The list of
127 available mechanisms MAY change after a successful STARTTLS
128 command [SMTP-TLS].
129
130 4. A new [SMTP] verb "AUTH" is defined.
131
132 5. An optional parameter using the keyword "AUTH" is added to the
133 MAIL FROM command, and extends the maximum line length of the
134 MAIL FROM command by 500 characters.
135
136 6. This extension is appropriate for the submission protocol
137 [SUBMIT].
138
1394. The AUTH Command
140
141 AUTH mechanism [initial-response]
142
143 Arguments:
144 mechanism: A string identifying a [SASL] authentication
145 mechanism.
146
147 initial-response: An optional initial client response. If
148 present, this response MUST be encoded as described in Section
149 4 of [BASE64] or contain a single character "=".
150
151 Restrictions:
152 After an AUTH command has been successfully completed, no more
153 AUTH commands may be issued in the same session. After a
154 successful AUTH command completes, a server MUST reject any
155 further AUTH commands with a 503 reply.
156
157 The AUTH command is not permitted during a mail transaction.
158 An AUTH command issued during a mail transaction MUST be
159 rejected with a 503 reply.
160
161 Discussion:
162 The AUTH command initiates a [SASL] authentication exchange
163 between the client and the server. The client identifies the
164 SASL mechanism to use with the first parameter of the AUTH
165 command. If the server supports the requested authentication
166 mechanism, it performs the SASL exchange to authenticate the
167
168
169
170Siemborski & Melnikov Standards Track [Page 3]
171
172RFC 4954 SMTP Service Extension for Authentication July 2007
173
174
175 user. Optionally, it also negotiates a security layer for
176 subsequent protocol interactions during this session. If the
177 requested authentication mechanism is invalid (e.g., is not
178 supported or requires an encryption layer), the server rejects
179 the AUTH command with a 504 reply. If the server supports the
180 [ESMTP-CODES] extension, it SHOULD return a 5.5.4 enhanced
181 response code.
182
183 The SASL authentication exchange consists of a series of
184 server challenges and client responses that are specific to
185 the chosen [SASL] mechanism.
186
187 A server challenge is sent as a 334 reply with the text part
188 containing the [BASE64] encoded string supplied by the SASL
189 mechanism. This challenge MUST NOT contain any text other
190 than the BASE64 encoded challenge.
191
192 A client response consists of a line containing a [BASE64]
193 encoded string. If the client wishes to cancel the
194 authentication exchange, it issues a line with a single "*".
195 If the server receives such a response, it MUST reject the
196 AUTH command by sending a 501 reply.
197
198 The optional initial response argument to the AUTH command is
199 used to save a round-trip when using authentication mechanisms
200 that support an initial client response. If the initial
201 response argument is omitted and the chosen mechanism requires
202 an initial client response, the server MUST proceed as defined
203 in Section 5.1 of [SASL]. In SMTP, a server challenge that
204 contains no data is defined as a 334 reply with no text part.
205 Note that there is still a space following the reply code, so
206 the complete response line is "334 ".
207
208 Note that the AUTH command is still subject to the line length
209 limitations defined in [SMTP]. If use of the initial response
210 argument would cause the AUTH command to exceed this length,
211 the client MUST NOT use the initial response parameter (and
212 instead proceed as defined in Section 5.1 of [SASL]).
213
214 If the client is transmitting an initial response of zero
215 length, it MUST instead transmit the response as a single
216 equals sign ("="). This indicates that the response is
217 present, but contains no data.
218
219 If the client uses an initial-response argument to the AUTH
220 command with a SASL mechanism in which the client does not
221 begin the authentication exchange, the server MUST reject the
222
223
224
225
226Siemborski & Melnikov Standards Track [Page 4]
227
228RFC 4954 SMTP Service Extension for Authentication July 2007
229
230
231 AUTH command with a 501 reply. Servers using the enhanced
232 status codes extension [ESMTP-CODES] SHOULD return an enhanced
233 status code of 5.7.0 in this case.
234
235 If the server cannot [BASE64] decode any client response, it
236 MUST reject the AUTH command with a 501 reply (and an enhanced
237 status code of 5.5.2). If the client cannot BASE64 decode any
238 of the server's challenges, it MUST cancel the authentication
239 using the "*" response. In particular, servers and clients
240 MUST reject (and not ignore) any character not explicitly
241 allowed by the BASE64 alphabet, and MUST reject any sequence
242 of BASE64 characters that contains the pad character ('=')
243 anywhere other than the end of the string (e.g., "=AAA" and
244 "AAA=BBB" are not allowed).
245
246 Note that these [BASE64] strings can be much longer than
247 normal SMTP commands. Clients and servers MUST be able to
248 handle the maximum encoded size of challenges and responses
249 generated by their supported authentication mechanisms. This
250 requirement is independent of any line length limitations the
251 client or server may have in other parts of its protocol
252 implementation. (At the time of writing of this document,
253 12288 octets is considered to be a sufficient line length
254 limit for handling of deployed authentication mechanisms.)
255 If, during an authentication exchange, the server receives a
256 line that is longer than the server's authentication buffer,
257 the server fails the AUTH command with the 500 reply. Servers
258 using the enhanced status codes extension [ESMTP-CODES] SHOULD
259 return an enhanced status code of 5.5.6 in this case.
260
261 The authorization identity generated by this [SASL] exchange
262 is a "simple username" (in the sense defined in [SASLprep]),
263 and both client and server SHOULD (*) use the [SASLprep]
264 profile of the [StringPrep] algorithm to prepare these names
265 for transmission or comparison. If preparation of the
266 authorization identity fails or results in an empty string
267 (unless it was transmitted as the empty string), the server
268 MUST fail the authentication.
269
270 (*) Note: Future revision of this specification may change this
271 requirement to MUST. Currently, the SHOULD is used in order to
272 avoid breaking the majority of existing implementations.
273
274 If the server is unable to authenticate the client, it SHOULD reject
275 the AUTH command with a 535 reply unless a more specific error code
276 is appropriate. Should the client successfully complete the
277 exchange, the SMTP server issues a 235 reply. (Note that the SMTP
278 protocol doesn't support the SASL feature of returning additional
279
280
281
282Siemborski & Melnikov Standards Track [Page 5]
283
284RFC 4954 SMTP Service Extension for Authentication July 2007
285
286
287 data with a successful outcome.) These status codes, along with
288 others defined by this extension, are discussed in Section 6 of this
289 document.
290
291 If a security layer is negotiated during the SASL exchange, it takes
292 effect for the client on the octet immediately following the CRLF
293 that concludes the last response generated by the client. For the
294 server, it takes effect immediately following the CRLF of its success
295 reply.
296
297 When a security layer takes effect, the SMTP protocol is reset to the
298 initial state (the state in SMTP after a server issues a 220 service
299 ready greeting). The server MUST discard any knowledge obtained from
300 the client, such as the EHLO argument, which was not obtained from
301 the SASL negotiation itself. Likewise, the client MUST discard any
302 knowledge obtained from the server, such as the list of SMTP service
303 extensions, which was not obtained from the SASL negotiation itself.
304 (Note that a client MAY compare the advertised SASL mechanisms before
305 and after authentication in order to detect an active down-
306 negotiation attack).
307
308 The client SHOULD send an EHLO command as the first command after a
309 successful SASL negotiation that results in the enabling of a
310 security layer.
311
312 When an entity (whether it is the client or the server end) is
313 sending data, and both [TLS] and SASL security layers are in effect,
314 the TLS encoding MUST be applied after the SASL encoding, regardless
315 of the order in which the layers were negotiated.
316
317 The service name specified by this protocol's profile of SASL is
318 "smtp". This service name is also to be used for the [SUBMIT]
319 protocol.
320
321 If an AUTH command fails, the client MAY proceed without
322 authentication. Alternatively, the client MAY try another
323 authentication mechanism or present different credentials by issuing
324 another AUTH
325
326 Note: A server implementation MUST implement a configuration in which
327 it does NOT permit any plaintext password mechanisms, unless either
328 the STARTTLS [SMTP-TLS] command has been negotiated or some other
329 mechanism that protects the session from password snooping has been
330 provided. Server sites SHOULD NOT use any configuration which
331 permits a plaintext password mechanism without such a protection
332 mechanism against password snooping.
333
334
335
336
337
338Siemborski & Melnikov Standards Track [Page 6]
339
340RFC 4954 SMTP Service Extension for Authentication July 2007
341
342
343 To ensure interoperability, client and server implementations of this
344 extension MUST implement the [PLAIN] SASL mechanism running over TLS
345 [TLS] [SMTP-TLS]. See also Section 15 for additional requirements on
346 implementations of [PLAIN] over [TLS].
347
348 Note that many existing client and server implementations implement
349 CRAM-MD5 [CRAM-MD5] SASL mechanism. In order to ensure
350 interoperability with deployed software, new implementations MAY
351 implement it; however, implementations should be aware that this SASL
352 mechanism doesn't provide any server authentication. Note that at
353 the time of writing of this document the SASL Working Group is
354 working on several replacement SASL mechanisms that provide server
355 authentication and other features.
356
357 When the AUTH command is used together with the [PIPELINING]
358 extension, it MUST be the last command in a pipelined group of
359 commands. The only exception to this rule is when the AUTH command
360 contains an initial response for a SASL mechanism that allows the
361 client to send data first, the SASL mechanism is known to complete in
362 one round-trip, and a security layer is not negotiated by the client.
363 Two examples of such SASL mechanisms are PLAIN [PLAIN] and EXTERNAL
364 [SASL].
365
3664.1. Examples
367
368 Here is an example of a client attempting AUTH using the [PLAIN] SASL
369 mechanism under a TLS layer, and making use of the initial client
370 response:
371
372 S: 220-smtp.example.com ESMTP Server
373 C: EHLO client.example.com
374 S: 250-smtp.example.com Hello client.example.com
375 S: 250-AUTH GSSAPI DIGEST-MD5
376 S: 250-ENHANCEDSTATUSCODES
377 S: 250 STARTTLS
378 C: STARTTLS
379 S: 220 Ready to start TLS
380 ... TLS negotiation proceeds, further commands
381 protected by TLS layer ...
382 C: EHLO client.example.com
383 S: 250-smtp.example.com Hello client.example.com
384 S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN
385 C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ=
386 S: 235 2.7.0 Authentication successful
387
388 Here is another client that is attempting AUTH PLAIN under a TLS
389 layer, this time without the initial response. Parts of the
390 negotiation before the TLS layer was established have been omitted:
391
392
393
394Siemborski & Melnikov Standards Track [Page 7]
395
396RFC 4954 SMTP Service Extension for Authentication July 2007
397
398
399 ... TLS negotiation proceeds, further commands
400 protected by TLS layer ...
401 C: EHLO client.example.com
402 S: 250-smtp.example.com Hello client.example.com
403 S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN
404 C: AUTH PLAIN
405 (note: there is a single space following the 334
406 on the following line)
407 S: 334
408 C: dGVzdAB0ZXN0ADEyMzQ=
409 S: 235 2.7.0 Authentication successful
410
411 Here is an example using CRAM-MD5 [CRAM-MD5], a mechanism in which
412 the client does not begin the authentication exchange, and includes a
413 server challenge:
414
415 S: 220-smtp.example.com ESMTP Server
416 C: EHLO client.example.com
417 S: 250-smtp.example.com Hello client.example.com
418 S: 250-AUTH DIGEST-MD5 CRAM-MD5
419 S: 250-ENHANCEDSTATUSCODES
420 S: 250 STARTTLS
421 C: AUTH CRAM-MD5
422 S: 334 PDQxOTI5NDIzNDEuMTI4Mjg0NzJAc291cmNlZm91ci5hbmRyZXcuY211LmVk
423 dT4=
424 C: cmpzMyBlYzNhNTlmZWQzOTVhYmExZWM2MzY3YzRmNGI0MWFjMA==
425 S: 235 2.7.0 Authentication successful
426
427 Here is an example of a client attempting AUTH EXTERNAL under TLS,
428 using the derived authorization ID (and thus a zero-length initial
429 client response).
430
431 S: 220-smtp.example.com ESMTP Server
432 C: EHLO client.example.com
433 S: 250-smtp.example.com Hello client.example.com
434 S: 250-AUTH GSSAPI DIGEST-MD5
435 S: 250-ENHANCEDSTATUSCODES
436 S: 250 STARTTLS
437 C: STARTTLS
438 S: 220 Ready to start TLS
439 ... TLS negotiation proceeds, further commands
440 protected by TLS layer ...
441 C: EHLO client.example.com
442 S: 250-smtp.example.com Hello client.example.com
443 S: 250 AUTH EXTERNAL GSSAPI DIGEST-MD5 PLAIN
444 C: AUTH EXTERNAL =
445 S: 235 2.7.0 Authentication successful
446
447
448
449
450Siemborski & Melnikov Standards Track [Page 8]
451
452RFC 4954 SMTP Service Extension for Authentication July 2007
453
454
4555. The AUTH Parameter to the MAIL FROM command
456
457 AUTH=mailbox
458
459 Arguments:
460 A <mailbox> (see Section 4.1.2 of [SMTP]) that is associated
461 with the identity that submitted the message to the delivery
462 system, or the two character sequence "<>" indicating such an
463 identity is unknown or insufficiently authenticated. To comply
464 with restrictions imposed on ESMTP parameters, the <mailbox> is
465 encoded inside an xtext. The syntax of an xtext is described in
466 Section 4 of [ESMTP-DSN].
467
468 Note:
469 For the purposes of this discussion, "authenticated identity"
470 refers to the identity (if any) derived from the authorization
471 identity of previous AUTH command, while the terms "authorized
472 identity" and "supplied <mailbox>" refer to the sender identity
473 that is being associated with a particular message. Note that
474 one authenticated identity may be able to identify messages as
475 being sent by any number of authorized identities within a
476 single session. For example, this may be the case when an SMTP
477 server (one authenticated identity) is processing its queue
478 (many messages with distinct authorized identities).
479
480 Discussion:
481 The optional AUTH parameter to the MAIL FROM command allows
482 cooperating agents in a trusted environment to communicate the
483 authorization identity associated with individual messages.
484
485 If the server trusts the authenticated identity of the client to
486 assert that the message was originally submitted by the supplied
487 <mailbox>, then the server SHOULD supply the same <mailbox> in
488 an AUTH parameter when relaying the message to any other server
489 which supports the AUTH extension.
490
491 For this reason, servers that advertise support for this
492 extension MUST support the AUTH parameter to the MAIL FROM
493 command even when the client has not authenticated itself to the
494 server.
495
496 A MAIL FROM parameter of AUTH=<> indicates that the original
497 submitter of the message is not known. The server MUST NOT
498 treat the message as having been originally submitted by the
499 authenticated identity that resulted from the AUTH command.
500
501
502
503
504
505
506Siemborski & Melnikov Standards Track [Page 9]
507
508RFC 4954 SMTP Service Extension for Authentication July 2007
509
510
511 If the AUTH parameter to the MAIL FROM command is not supplied,
512 the client has authenticated, and the server believes the
513 message is an original submission, the server MAY generate a
514 <mailbox> from the user's authenticated identity for use in an
515 AUTH parameter when relaying the message to any server which
516 supports the AUTH extension. The generated <mailbox> is
517 implementation specific, but it MUST conform to the syntax of
518 [SMTP]. If the implementation cannot generate a valid
519 <mailbox>, it MUST transmit AUTH=<> when relaying this message.
520
521 If the server does not sufficiently trust the authenticated
522 identity of the client, or if the client is not authenticated,
523 then the server MUST behave as if the AUTH=<> parameter was
524 supplied. The server MAY, however, write the value of any
525 supplied AUTH parameter to a log file.
526
527 If an AUTH=<> parameter was supplied, either explicitly or due
528 to the requirement in the previous paragraph, then the server
529 MUST supply the AUTH=<> parameter when relaying the message to
530 any server which it has authenticated to using the AUTH
531 extension.
532
533 A server MAY treat expansion of a mailing list as a new
534 submission, setting the AUTH parameter to the mailing list
535 address or mailing list administration address when relaying the
536 message to list subscribers.
537
538 Note that an implementation which is hard-coded to treat all
539 clients as being insufficiently trusted is compliant with this
540 specification. In that case, the implementation does nothing
541 more than parse and discard syntactically valid AUTH parameters
542 to the MAIL FROM command, and supply AUTH=<> parameters to any
543 servers that it authenticates to.
544
5455.1. Examples
546
547 An example where the original identity of the sender is trusted and
548 known:
549
550 C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com
551 S: 250 OK
552
553 One example where the identity of the sender is not trusted or is
554 otherwise being suppressed by the client:
555
556 C: MAIL FROM:<john+@example.org> AUTH=<>
557 S: 250 OK
558
559
560
561
562Siemborski & Melnikov Standards Track [Page 10]
563
564RFC 4954 SMTP Service Extension for Authentication July 2007
565
566
5676. Status Codes
568
569 The following error codes may be used to indicate various success or
570 failure conditions. Servers that return enhanced status codes
571 [ESMTP-CODES] SHOULD use the enhanced codes suggested here.
572
573 235 2.7.0 Authentication Succeeded
574
575 This response to the AUTH command indicates that the authentication
576 was successful.
577
578 432 4.7.12 A password transition is needed
579
580 This response to the AUTH command indicates that the user needs to
581 transition to the selected authentication mechanism. This is
582 typically done by authenticating once using the [PLAIN]
583 authentication mechanism. The selected mechanism SHOULD then work
584 for authentications in subsequent sessions.
585
586 454 4.7.0 Temporary authentication failure
587
588 This response to the AUTH command indicates that the authentication
589 failed due to a temporary server failure. The client SHOULD NOT
590 prompt the user for another password in this case, and should instead
591 notify the user of server failure.
592
593 534 5.7.9 Authentication mechanism is too weak
594
595 This response to the AUTH command indicates that the selected
596 authentication mechanism is weaker than server policy permits for
597 that user. The client SHOULD retry with a new authentication
598 mechanism.
599
600 535 5.7.8 Authentication credentials invalid
601
602 This response to the AUTH command indicates that the authentication
603 failed due to invalid or insufficient authentication credentials. In
604 this case, the client SHOULD ask the user to supply new credentials
605 (such as by presenting a password dialog box).
606
607 500 5.5.6 Authentication Exchange line is too long
608
609 This response to the AUTH command indicates that the authentication
610 failed due to the client sending a [BASE64] response that is longer
611 than the maximum buffer size available for the currently selected
612 SASL mechanism.
613
614
615
616
617
618Siemborski & Melnikov Standards Track [Page 11]
619
620RFC 4954 SMTP Service Extension for Authentication July 2007
621
622
623 530 5.7.0 Authentication required
624
625 This response SHOULD be returned by any command other than AUTH,
626 EHLO, HELO, NOOP, RSET, or QUIT when server policy requires
627 authentication in order to perform the requested action and
628 authentication is not currently in force.
629
630 538 5.7.11 Encryption required for requested authentication
631 mechanism
632
633 This response to the AUTH command indicates that the selected
634 authentication mechanism may only be used when the underlying SMTP
635 connection is encrypted. Note that this response code is documented
636 here for historical purposes only. Modern implementations SHOULD NOT
637 advertise mechanisms that are not permitted due to lack of
638 encryption, unless an encryption layer of sufficient strength is
639 currently being employed.
640
641 This document adds several new enhanced status codes to the list
642 defined in [ENHANCED]:
643
644 The following 3 Enhanced Status Codes were defined above:
645
646 5.7.8 Authentication credentials invalid
647 5.7.9 Authentication mechanism is too weak
648 5.7.11 Encryption required for requested authentication mechanism
649
650 X.5.6 Authentication Exchange line is too long
651
652 This enhanced status code SHOULD be returned when the server fails
653 the AUTH command due to the client sending a [BASE64] response which
654 is longer than the maximum buffer size available for the currently
655 selected SASL mechanism. This is useful for both permanent and
656 persistent transient errors.
657
6587. Additional Requirements on Servers
659
660 As described in Section 4.4 of [SMTP], an SMTP server that receives a
661 message for delivery or further processing MUST insert the
662 "Received:" header field at the beginning of the message content.
663 This document places additional requirements on the content of a
664 generated "Received:" header field. Upon successful authentication,
665 a server SHOULD use the "ESMTPA" or the "ESMTPSA" [SMTP-TT] (when
666 appropriate) keyword in the "with" clause of the Received header
667 field.
668
669
670
671
672
673
674Siemborski & Melnikov Standards Track [Page 12]
675
676RFC 4954 SMTP Service Extension for Authentication July 2007
677
678
6798. Formal Syntax
680
681 The following syntax specification uses the Augmented Backus-Naur
682 Form notation as specified in [ABNF]. Non-terminals referenced but
683 not defined below are as defined by [ABNF] or [SASL]. The non-
684 terminal <mailbox> is defined in [SMTP].
685
686 Except as noted otherwise, all alphabetic characters are case-
687 insensitive. The use of upper or lower case characters to define
688 token strings is for editorial clarity only. Implementations MUST
689 accept these strings in a case-insensitive fashion.
690
691 hexchar = "+" HEXDIG HEXDIG
692
693 xchar = %x21-2A / %x2C-3C / %x3E-7E
694 ;; US-ASCII except for "+", "=", SP, and CTL
695
696 xtext = *(xchar / hexchar)
697 ;; non-US-ASCII is only allowed as hexchar
698
699 auth-command = "AUTH" SP sasl-mech [SP initial-response]
700 *(CRLF [base64]) [CRLF cancel-response]
701 CRLF
702 ;; <sasl-mech> is defined in [SASL]
703
704 auth-param = "AUTH=" xtext
705 ;; Parameter to the MAIL FROM command.
706 ;; This non-terminal complies with
707 ;; syntax defined by esmtp-param [SMTP].
708 ;;
709 ;; The decoded form of the xtext MUST be
710 ;; either a <mailbox> or the two
711 ;; characters "<>"
712
713 base64 = base64-terminal /
714 ( 1*(4base64-char) [base64-terminal] )
715
716 base64-char = ALPHA / DIGIT / "+" / "/"
717 ;; Case-sensitive
718
719 base64-terminal = (2base64-char "==") / (3base64-char "=")
720
721 continue-req = "334" SP [base64] CRLF
722 ;; Intermediate response to the AUTH
723 ;; command.
724 ;; This non-terminal complies with
725 ;; syntax defined by Reply-line [SMTP].
726
727
728
729
730Siemborski & Melnikov Standards Track [Page 13]
731
732RFC 4954 SMTP Service Extension for Authentication July 2007
733
734
735 initial-response= base64 / "="
736
737 cancel-response = "*"
738
7399. Security Considerations
740
741 Security issues are discussed throughout this memo.
742
743 If a client uses this extension to get an encrypted tunnel through an
744 insecure network to a cooperating server, it needs to be configured
745 to never send mail to that server when the connection is not mutually
746 authenticated and encrypted. Otherwise, an attacker could steal the
747 client's mail by hijacking the [SMTP] connection and either
748 pretending the server does not support the Authentication extension
749 or causing all AUTH commands to fail.
750
751 Before the [SASL] negotiation has begun, any protocol interactions
752 are performed in the clear and may be modified by an active attacker.
753 For this reason, clients and servers MUST discard any knowledge
754 obtained prior to the start of the SASL negotiation upon the
755 establishment of a security layer.
756
757 This mechanism does not protect the TCP port, so an active attacker
758 may redirect a relay connection attempt (i.e., a connection between
759 two Mail Transfer Agents (MTAs)) to the submission port [SUBMIT].
760 The AUTH=<> parameter prevents such an attack from causing a relayed
761 message and, in the absence of other envelope authentication, from
762 picking up the authentication of the relay client.
763
764 A message submission client may require the user to authenticate
765 whenever a suitable [SASL] mechanism is advertised. Therefore, it
766 may not be desirable for a submission server [SUBMIT] to advertise a
767 SASL mechanism when use of that mechanism grants the clients no
768 benefits over anonymous submission.
769
770 Servers MAY implement a policy whereby the connection is dropped
771 after a number of failed authentication attempts. If they do so,
772 they SHOULD NOT drop the connection until at least 3 attempts to
773 authenticate have failed.
774
775 If an implementation supports SASL mechanisms that are vulnerable to
776 passive eavesdropping attacks (such as [PLAIN]), then the
777 implementation MUST support at least one configuration where these
778 SASL mechanisms are not advertised or used without the presence of an
779 external security layer such as [TLS].
780
781
782
783
784
785
786Siemborski & Melnikov Standards Track [Page 14]
787
788RFC 4954 SMTP Service Extension for Authentication July 2007
789
790
791 This extension is not intended to replace or be used instead of end-
792 to-end message signature and encryption systems such as [S/MIME] or
793 [PGP]. This extension addresses a different problem than end-to-end
794 systems; it has the following key differences:
795
796 1. It is generally useful only within a trusted enclave.
797
798 2. It protects the entire envelope of a message, not just the
799 message's body.
800
801 3. It authenticates the message submission, not authorship of the
802 message content.
803
804 4. When mutual authentication is used along with a security layer,
805 it can give the sender some assurance that the message was
806 successfully delivered to the next hop.
807
808 Additional security considerations are mentioned in the [SASL]
809 specification. Additional security considerations specific to a
810 particular SASL mechanism are described in the relevant
811 specification. Additional security considerations for [PLAIN] over
812 [TLS] are mentioned in Section 15 of this document.
813
81410. IANA Considerations
815
816 IANA updated the entry for the "smtp" SASL protocol name to point at
817 this document.
818
819 IANA updated the registration of the Authentication SMTP service
820 extension as defined in Section 3 of this document. This registry is
821 currently located at <http://www.iana.org/assignments/mail-
822 parameters>.
823
82411. Normative References
825
826 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
827 Specifications: ABNF", RFC 4234, October 2005.
828
829 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
830 Encodings", RFC 4648, October 2006.
831
832 [ESMTP-CODES] Freed, N., "SMTP Service Extension for Returning
833 Enhanced Error Codes", RFC 2034, October 1996.
834
835 [ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
836 3463, January 2003.
837
838
839
840
841
842Siemborski & Melnikov Standards Track [Page 15]
843
844RFC 4954 SMTP Service Extension for Authentication July 2007
845
846
847 [ESMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP)
848 Service Extension Delivery Status Notifications
849 (DSNs)", RFC 3461, January 2003.
850
851 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
852 Requirement Levels", BCP 14, RFC 2119, March 1997.
853
854 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication
855 and Security Layer (SASL)", RFC 4422, June 2006.
856
857 [SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User
858 Names and Passwords", RFC 4013, February 2005.
859
860 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
861 April 2001.
862
863 [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP
864 over Transport Layer Security", RFC 3207, February
865 2002.
866
867 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
868 Internationalized Strings ("stringprep")", RFC 3454,
869 December 2002.
870
871 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for
872 Mail", RFC 4409, April 2006.
873
874 [SMTP-TT] Newman, C., "ESMTP and LMTP Transmission Types
875 Registration", RFC 3848, July 2004.
876
877 [PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and
878 Security Layer (SASL) Mechanism", RFC 4616, August
879 2006.
880
881 [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
882 X.509 Public Key Infrastructure Certificate and
883 Certificate Revocation List (CRL) Profile", RFC 3280,
884 April 2002.
885
88612. Informative References
887
888 [PGP] Elkins, M., "MIME Security with Pretty Good Privacy
889 (PGP)", RFC 2015, October 1996.
890
891 [S/MIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
892 Extensions (S/MIME) Version 3.1 Message Specification",
893 RFC 3851, July 2004.
894
895
896
897
898Siemborski & Melnikov Standards Track [Page 16]
899
900RFC 4954 SMTP Service Extension for Authentication July 2007
901
902
903 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer
904 Security (TLS) Protocol Version 1.1", RFC 4346, April
905 2006.
906
907 [PIPELINING] Freed, N., "SMTP Service Extension for Command
908 Pipelining", STD 60, RFC 2920, September 2000.
909
910 [CRAM-MD5] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
911 AUTHorize Extension for Simple Challenge/Response", RFC
912 2195, September 1997.
913
91413. Acknowledgments
915
916 The editors would like to acknowledge the contributions of John Myers
917 and other contributors to RFC 2554, on which this document draws from
918 heavily.
919
920 The editors would also like to thank Ken Murchison, Mark Crispin,
921 Chris Newman, David Wilson, Dave Cridland, Frank Ellermann, Ned
922 Freed, John Klensin, Tony Finch, Abhijit Menon-Sen, Philip Guenther,
923 Sam Hartman, Russ Housley, Cullen Jennings, and Lisa Dusseault for
924 the time they devoted to reviewing of this document and/or for the
925 comments received.
926
92714. Additional Requirements When Using SASL PLAIN over TLS
928
929 This section is normative for SMTP implementations that support SASL
930 [PLAIN] over [TLS].
931
932 If an SMTP client is willing to use SASL PLAIN over TLS to
933 authenticate to the SMTP server, the client verifies the server
934 certificate according to the rules of [X509]. If the server has not
935 provided any certificate, or if the certificate verification fails,
936 the client MUST NOT attempt to authenticate using the SASL PLAIN
937 mechanism.
938
939 After a successful [TLS] negotiation, the client MUST check its
940 understanding of the server hostname against the server's identity as
941 presented in the server Certificate message, in order to prevent
942 man-in-the-middle attacks. If the match fails, the client MUST NOT
943 attempt to authenticate using the SASL PLAIN mechanism. Matching is
944 performed according to the following rules:
945
946 The client MUST use the server hostname it used to open the
947 connection as the value to compare against the server name as
948 expressed in the server certificate. The client MUST NOT use
949
950
951
952
953
954Siemborski & Melnikov Standards Track [Page 17]
955
956RFC 4954 SMTP Service Extension for Authentication July 2007
957
958
959 any form of the server hostname derived from an insecure remote
960 source (e.g., insecure DNS lookup). CNAME canonicalization is
961 not done.
962
963 If a subjectAltName extension of type dNSName is present in the
964 certificate, it SHOULD be used as the source of the server's
965 identity.
966
967 Matching is case-insensitive.
968
969 A "*" wildcard character MAY be used as the leftmost name
970 component in the certificate. For example, *.example.com would
971 match a.example.com, foo.example.com, etc., but would not match
972 example.com.
973
974 If the certificate contains multiple names (e.g., more than one
975 dNSName field), then a match with any one of the fields is
976 considered acceptable.
977
97815. Changes since RFC 2554
979
980 1. Clarified that servers MUST support the use of the AUTH=mailbox
981 parameter to MAIL FROM, even when the client is not
982 authenticated.
983
984 2. Clarified the initial-client-send requirements, and give
985 additional examples.
986
987 3. Updated references to newer versions of various specifications.
988
989 4. Required SASL PLAIN (over TLS) as mandatory-to-implement.
990
991 5. Clarified that the mechanism list can change.
992
993 6. Deprecated the use of the 538 response code.
994
995 7. Added the use of the SASLprep profile for preparing authorization
996 identities.
997
998 8. Substantial cleanup of response codes and indicated suggested
999 enhanced response codes. Also indicated what response codes
1000 should result in a client prompting the user for new credentials.
1001
1002 9. Updated ABNF section to use RFC 4234.
1003
1004 10. Clarified interaction with SMTP PIPELINING extension.
1005
1006 11. Added a reference to RFC 3848.
1007
1008
1009
1010Siemborski & Melnikov Standards Track [Page 18]
1011
1012RFC 4954 SMTP Service Extension for Authentication July 2007
1013
1014
1015 12. Added a new Enhanced Status Code for "authentication line too
1016 long" case.
1017
1018 13. Other general editorial clarifications.
1019
1020Editors' Addresses
1021
1022 Robert Siemborski
1023 Google, Inc.
1024 1600 Ampitheatre Parkway
1025 Mountain View, CA 94043, USA
1026
1027 Phone: +1 650 623 6925
1028 EMail: robsiemb@google.com
1029
1030
1031 Alexey Melnikov
1032 Isode Limited
1033 5 Castle Business Village, 36 Station Road,
1034 Hampton, Middlesex, TW12 2BX, UK
1035
1036 EMail: Alexey.Melnikov@isode.com
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066Siemborski & Melnikov Standards Track [Page 19]
1067
1068RFC 4954 SMTP Service Extension for Authentication July 2007
1069
1070
1071Full Copyright Statement
1072
1073 Copyright (C) The IETF Trust (2007).
1074
1075 This document is subject to the rights, licenses and restrictions
1076 contained in BCP 78, and except as set forth therein, the authors
1077 retain all their rights.
1078
1079 This document and the information contained herein are provided on an
1080 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1081 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1082 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1083 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1084 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1085 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1086
1087Intellectual Property
1088
1089 The IETF takes no position regarding the validity or scope of any
1090 Intellectual Property Rights or other rights that might be claimed to
1091 pertain to the implementation or use of the technology described in
1092 this document or the extent to which any license under such rights
1093 might or might not be available; nor does it represent that it has
1094 made any independent effort to identify any such rights. Information
1095 on the procedures with respect to rights in RFC documents can be
1096 found in BCP 78 and BCP 79.
1097
1098 Copies of IPR disclosures made to the IETF Secretariat and any
1099 assurances of licenses to be made available, or the result of an
1100 attempt made to obtain a general license or permission for the use of
1101 such proprietary rights by implementers or users of this
1102 specification can be obtained from the IETF on-line IPR repository at
1103 http://www.ietf.org/ipr.
1104
1105 The IETF invites any interested party to bring to its attention any
1106 copyrights, patents or patent applications, or other proprietary
1107 rights that may cover technology that may be required to implement
1108 this standard. Please address the information to the IETF at
1109 ietf-ipr@ietf.org.
1110
1111Acknowledgement
1112
1113 Funding for the RFC Editor function is currently provided by the
1114 Internet Society.
1115
1116
1117
1118
1119
1120
1121
1122Siemborski & Melnikov Standards Track [Page 20]
1123