Commit

Author:

Hash:

Timestamp:

+1742 -0 +/-2 browse

Kevin Schoon [me@kevinschoon.com]

e538dbe3c2dab6d4375e9743e738ab3f62998476

Sun, 01 Sep 2024 18:56:30 +0000 (1.2 years ago)

add some more rfcs
1diff --git a/rfcs/rfc4616.txt b/rfcs/rfc4616.txt
2new file mode 100644
3index 0000000..991189d
4--- /dev/null
5+++ b/rfcs/rfc4616.txt
6 @@ -0,0 +1,619 @@
7+
8+
9+
10+
11+
12+
13+ Network Working Group K. Zeilenga, Ed.
14+ Request for Comments: 4616 OpenLDAP Foundation
15+ Updates: 2595 August 2006
16+ Category: Standards Track
17+
18+
19+ The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
20+
21+ Status of This Memo
22+
23+ This document specifies an Internet standards track protocol for the
24+ Internet community, and requests discussion and suggestions for
25+ improvements. Please refer to the current edition of the "Internet
26+ Official Protocol Standards" (STD 1) for the standardization state
27+ and status of this protocol. Distribution of this memo is unlimited.
28+
29+ Copyright Notice
30+
31+ Copyright (C) The Internet Society (2006).
32+
33+ Abstract
34+
35+ This document defines a simple clear-text user/password Simple
36+ Authentication and Security Layer (SASL) mechanism called the PLAIN
37+ mechanism. The PLAIN mechanism is intended to be used, in
38+ combination with data confidentiality services provided by a lower
39+ layer, in protocols that lack a simple password authentication
40+ command.
41+
42+
43+
44+
45+
46+
47+
48+
49+
50+
51+
52+
53+
54+
55+
56+
57+
58+
59+
60+
61+
62+
63+
64+ Zeilenga Standards Track [Page 1]
65+
66+ RFC 4616 The PLAIN SASL Mechanism August 2006
67+
68+
69+ 1. Introduction
70+
71+ Clear-text, multiple-use passwords are simple, interoperate with
72+ almost all existing operating system authentication databases, and
73+ are useful for a smooth transition to a more secure password-based
74+ authentication mechanism. The drawback is that they are unacceptable
75+ for use over network connections where data confidentiality is not
76+ ensured.
77+
78+ This document defines the PLAIN Simple Authentication and Security
79+ Layer ([SASL]) mechanism for use in protocols with no clear-text
80+ login command (e.g., [ACAP] or [SMTP-AUTH]). This document updates
81+ RFC 2595, replacing Section 6. Changes since RFC 2595 are detailed
82+ in Appendix A.
83+
84+ The name associated with this mechanism is "PLAIN".
85+
86+ The PLAIN SASL mechanism does not provide a security layer.
87+
88+ The PLAIN mechanism should not be used without adequate data security
89+ protection as this mechanism affords no integrity or confidentiality
90+ protections itself. The mechanism is intended to be used with data
91+ security protections provided by application-layer protocol,
92+ generally through its use of Transport Layer Security ([TLS])
93+ services.
94+
95+ By default, implementations SHOULD advertise and make use of the
96+ PLAIN mechanism only when adequate data security services are in
97+ place. Specifications for IETF protocols that indicate that this
98+ mechanism is an applicable authentication mechanism MUST mandate that
99+ implementations support an strong data security service, such as TLS.
100+
101+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
102+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
103+ document are to be interpreted as described in [Keywords].
104+
105+ 2. PLAIN SASL Mechanism
106+
107+ The mechanism consists of a single message, a string of [UTF-8]
108+ encoded [Unicode] characters, from the client to the server. The
109+ client presents the authorization identity (identity to act as),
110+ followed by a NUL (U+0000) character, followed by the authentication
111+ identity (identity whose password will be used), followed by a NUL
112+ (U+0000) character, followed by the clear-text password. As with
113+ other SASL mechanisms, the client does not provide an authorization
114+ identity when it wishes the server to derive an identity from the
115+ credentials and use that as the authorization identity.
116+
117+
118+
119+
120+ Zeilenga Standards Track [Page 2]
121+
122+ RFC 4616 The PLAIN SASL Mechanism August 2006
123+
124+
125+ The formal grammar for the client message using Augmented BNF [ABNF]
126+ follows.
127+
128+ message = [authzid] UTF8NUL authcid UTF8NUL passwd
129+ authcid = 1*SAFE ; MUST accept up to 255 octets
130+ authzid = 1*SAFE ; MUST accept up to 255 octets
131+ passwd = 1*SAFE ; MUST accept up to 255 octets
132+ UTF8NUL = %x00 ; UTF-8 encoded NUL character
133+
134+ SAFE = UTF1 / UTF2 / UTF3 / UTF4
135+ ;; any UTF-8 encoded Unicode character except NUL
136+
137+ UTF1 = %x01-7F ;; except NUL
138+ UTF2 = %xC2-DF UTF0
139+ UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
140+ %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
141+ UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
142+ %xF4 %x80-8F 2(UTF0)
143+ UTF0 = %x80-BF
144+
145+ The authorization identity (authzid), authentication identity
146+ (authcid), password (passwd), and NUL character deliminators SHALL be
147+ transferred as [UTF-8] encoded strings of [Unicode] characters. As
148+ the NUL (U+0000) character is used as a deliminator, the NUL (U+0000)
149+ character MUST NOT appear in authzid, authcid, or passwd productions.
150+
151+ The form of the authzid production is specific to the application-
152+ level protocol's SASL profile [SASL]. The authcid and passwd
153+ productions are form-free. Use of non-visible characters or
154+ characters that a user may be unable to enter on some keyboards is
155+ discouraged.
156+
157+ Servers MUST be capable of accepting authzid, authcid, and passwd
158+ productions up to and including 255 octets. It is noted that the
159+ UTF-8 encoding of a Unicode character may be as long as 4 octets.
160+
161+ Upon receipt of the message, the server will verify the presented (in
162+ the message) authentication identity (authcid) and password (passwd)
163+ with the system authentication database, and it will verify that the
164+ authentication credentials permit the client to act as the (presented
165+ or derived) authorization identity (authzid). If both steps succeed,
166+ the user is authenticated.
167+
168+ The presented authentication identity and password strings, as well
169+ as the database authentication identity and password strings, are to
170+ be prepared before being used in the verification process. The
171+ [SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED
172+ preparation algorithm. The SASLprep preparation algorithm is
173+
174+
175+
176+ Zeilenga Standards Track [Page 3]
177+
178+ RFC 4616 The PLAIN SASL Mechanism August 2006
179+
180+
181+ recommended to improve the likelihood that comparisons behave in an
182+ expected manner. The SASLprep preparation algorithm is not mandatory
183+ so as to allow the server to employ other preparation algorithms
184+ (including none) when appropriate. For instance, use of a different
185+ preparation algorithm may be necessary for the server to interoperate
186+ with an external system.
187+
188+ When preparing the presented strings using [SASLPrep], the presented
189+ strings are to be treated as "query" strings (Section 7 of
190+ [StringPrep]) and hence unassigned code points are allowed to appear
191+ in their prepared output. When preparing the database strings using
192+ [SASLPrep], the database strings are to be treated as "stored"
193+ strings (Section 7 of [StringPrep]) and hence unassigned code points
194+ are prohibited from appearing in their prepared output.
195+
196+ Regardless of the preparation algorithm used, if the output of a
197+ non-invertible function (e.g., hash) of the expected string is
198+ stored, the string MUST be prepared before input to that function.
199+
200+ Regardless of the preparation algorithm used, if preparation fails or
201+ results in an empty string, verification SHALL fail.
202+
203+ When no authorization identity is provided, the server derives an
204+ authorization identity from the prepared representation of the
205+ provided authentication identity string. This ensures that the
206+ derivation of different representations of the authentication
207+ identity produces the same authorization identity.
208+
209+ The server MAY use the credentials to initialize any new
210+ authentication database, such as one suitable for [CRAM-MD5] or
211+ [DIGEST-MD5].
212+
213+ 3. Pseudo-Code
214+
215+ This section provides pseudo-code illustrating the verification
216+ process (using hashed passwords and the SASLprep preparation
217+ function) discussed above. This section is not definitive.
218+
219+ boolean Verify(string authzid, string authcid, string passwd) {
220+ string pAuthcid = SASLprep(authcid, true); # prepare authcid
221+ string pPasswd = SASLprep(passwd, true); # prepare passwd
222+ if (pAuthcid == NULL || pPasswd == NULL) {
223+ return false; # preparation failed
224+ }
225+ if (pAuthcid == "" || pPasswd == "") {
226+ return false; # empty prepared string
227+ }
228+
229+
230+
231+
232+ Zeilenga Standards Track [Page 4]
233+
234+ RFC 4616 The PLAIN SASL Mechanism August 2006
235+
236+
237+ storedHash = FetchPasswordHash(pAuthcid);
238+ if (storedHash == NULL || storedHash == "") {
239+ return false; # error or unknown authcid
240+ }
241+
242+ if (!Compare(storedHash, Hash(pPasswd))) {
243+ return false; # incorrect password
244+ }
245+
246+ if (authzid == NULL ) {
247+ authzid = DeriveAuthzid(pAuthcid);
248+ if (authzid == NULL || authzid == "") {
249+ return false; # could not derive authzid
250+ }
251+ }
252+
253+ if (!Authorize(pAuthcid, authzid)) {
254+ return false; # not authorized
255+ }
256+
257+ return true;
258+ }
259+
260+ The second parameter of the SASLprep function, when true, indicates
261+ that unassigned code points are allowed in the input. When the
262+ SASLprep function is called to prepare the password prior to
263+ computing the stored hash, the second parameter would be false.
264+
265+ The second parameter provided to the Authorize function is not
266+ prepared by this code. The application-level SASL profile should be
267+ consulted to determine what, if any, preparation is necessary.
268+
269+ Note that the DeriveAuthzid and Authorize functions (whether
270+ implemented as one function or two, whether designed in a manner in
271+ which these functions or whether the mechanism implementation can be
272+ reused elsewhere) require knowledge and understanding of mechanism
273+ and the application-level protocol specification and/or
274+ implementation details to implement.
275+
276+ Note that the Authorize function outcome is clearly dependent on
277+ details of the local authorization model and policy. Both functions
278+ may be dependent on other factors as well.
279+
280+
281+
282+
283+
284+
285+
286+
287+
288+ Zeilenga Standards Track [Page 5]
289+
290+ RFC 4616 The PLAIN SASL Mechanism August 2006
291+
292+
293+ 4. Examples
294+
295+ This section provides examples of PLAIN authentication exchanges.
296+ The examples are intended to help the readers understand the above
297+ text. The examples are not definitive.
298+
299+ "C:" and "S:" indicate lines sent by the client and server,
300+ respectively. "<NUL>" represents a single NUL (U+0000) character.
301+ The Application Configuration Access Protocol ([ACAP]) is used in the
302+ examples.
303+
304+ The first example shows how the PLAIN mechanism might be used for
305+ user authentication.
306+
307+ S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
308+ C: a001 STARTTLS
309+ S: a001 OK "Begin TLS negotiation now"
310+ <TLS negotiation, further commands are under TLS layer>
311+ S: * ACAP (SASL "CRAM-MD5" "PLAIN")
312+ C: a002 AUTHENTICATE "PLAIN"
313+ S: + ""
314+ C: {21}
315+ C: <NUL>tim<NUL>tanstaaftanstaaf
316+ S: a002 OK "Authenticated"
317+
318+ The second example shows how the PLAIN mechanism might be used to
319+ attempt to assume the identity of another user. In this example, the
320+ server rejects the request. Also, this example makes use of the
321+ protocol optional initial response capability to eliminate a round-
322+ trip.
323+
324+ S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
325+ C: a001 STARTTLS
326+ S: a001 OK "Begin TLS negotiation now"
327+ <TLS negotiation, further commands are under TLS layer>
328+ S: * ACAP (SASL "CRAM-MD5" "PLAIN")
329+ C: a002 AUTHENTICATE "PLAIN" {20+}
330+ C: Ursel<NUL>Kurt<NUL>xipj3plmq
331+ S: a002 NO "Not authorized to requested authorization identity"
332+
333+ 5. Security Considerations
334+
335+ As the PLAIN mechanism itself provided no integrity or
336+ confidentiality protections, it should not be used without adequate
337+ external data security protection, such as TLS services provided by
338+ many application-layer protocols. By default, implementations SHOULD
339+ NOT advertise and SHOULD NOT make use of the PLAIN mechanism unless
340+ adequate data security services are in place.
341+
342+
343+
344+ Zeilenga Standards Track [Page 6]
345+
346+ RFC 4616 The PLAIN SASL Mechanism August 2006
347+
348+
349+ When the PLAIN mechanism is used, the server gains the ability to
350+ impersonate the user to all services with the same password
351+ regardless of any encryption provided by TLS or other confidentiality
352+ protection mechanisms. Whereas many other authentication mechanisms
353+ have similar weaknesses, stronger SASL mechanisms address this issue.
354+ Clients are encouraged to have an operational mode where all
355+ mechanisms that are likely to reveal the user's password to the
356+ server are disabled.
357+
358+ General [SASL] security considerations apply to this mechanism.
359+
360+ Unicode, [UTF-8], and [StringPrep] security considerations also
361+ apply.
362+
363+ 6. IANA Considerations
364+
365+ The SASL Mechanism registry [IANA-SASL] entry for the PLAIN mechanism
366+ has been updated by the IANA to reflect that this document now
367+ provides its technical specification.
368+
369+ To: iana@iana.org
370+ Subject: Updated Registration of SASL mechanism PLAIN
371+
372+ SASL mechanism name: PLAIN
373+ Security considerations: See RFC 4616.
374+ Published specification (optional, recommended): RFC 4616
375+ Person & email address to contact for further information:
376+ Kurt Zeilenga <kurt@openldap.org>
377+ IETF SASL WG <ietf-sasl@imc.org>
378+ Intended usage: COMMON
379+ Author/Change controller: IESG <iesg@ietf.org>
380+ Note: Updates existing entry for PLAIN
381+
382+ 7. Acknowledgements
383+
384+ This document is a revision of RFC 2595 by Chris Newman. Portions of
385+ the grammar defined in Section 2 were borrowed from [UTF-8] by
386+ Francois Yergeau.
387+
388+ This document is a product of the IETF Simple Authentication and
389+ Security Layer (SASL) Working Group.
390+
391+
392+
393+
394+
395+
396+
397+
398+
399+
400+ Zeilenga Standards Track [Page 7]
401+
402+ RFC 4616 The PLAIN SASL Mechanism August 2006
403+
404+
405+ 8. Normative References
406+
407+ [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
408+ Syntax Specifications: ABNF", RFC 4234, October 2005.
409+
410+ [Keywords] Bradner, S., "Key words for use in RFCs to Indicate
411+ Requirement Levels", BCP 14, RFC 2119, March 1997.
412+
413+ [SASL] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
414+ Authentication and Security Layer (SASL)", RFC 4422,
415+ June 2006.
416+
417+ [SASLPrep] Zeilenga, K., "SASLprep: Stringprep Profile for User
418+ Names and Passwords", RFC 4013, February 2005.
419+
420+ [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
421+ Internationalized Strings ("stringprep")", RFC 3454,
422+ December 2002.
423+
424+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
425+ 3.2.0" is defined by "The Unicode Standard, Version
426+ 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
427+ 61633-5), as amended by the "Unicode Standard Annex
428+ #27: Unicode 3.1"
429+ (http://www.unicode.org/reports/tr27/) and by the
430+ "Unicode Standard Annex #28: Unicode 3.2"
431+ (http://www.unicode.org/reports/tr28/).
432+
433+ [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
434+ 10646", STD 63, RFC 3629, November 2003.
435+
436+ [TLS] Dierks, T. and E. Rescorla, "The Transport Layer
437+ Security (TLS) Protocol Version 1.1", RFC 4346, April
438+ 2006.
439+
440+ 9. Informative References
441+
442+ [ACAP] Newman, C. and J. Myers, "ACAP -- Application
443+ Configuration Access Protocol", RFC 2244, November
444+ 1997.
445+
446+ [CRAM-MD5] Nerenberg, L., Ed., "The CRAM-MD5 SASL Mechanism", Work
447+ in Progress, June 2006.
448+
449+ [DIGEST-MD5] Melnikov, A., Ed., "Using Digest Authentication as a
450+ SASL Mechanism", Work in Progress, June 2006.
451+
452+
453+
454+
455+
456+ Zeilenga Standards Track [Page 8]
457+
458+ RFC 4616 The PLAIN SASL Mechanism August 2006
459+
460+
461+ [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
462+ MECHANISMS",
463+ <http://www.iana.org/assignments/sasl-mechanisms>.
464+
465+ [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
466+ RFC 2554, March 1999.
467+
468+
469+
470+
471+
472+
473+
474+
475+
476+
477+
478+
479+
480+
481+
482+
483+
484+
485+
486+
487+
488+
489+
490+
491+
492+
493+
494+
495+
496+
497+
498+
499+
500+
501+
502+
503+
504+
505+
506+
507+
508+
509+
510+
511+
512+ Zeilenga Standards Track [Page 9]
513+
514+ RFC 4616 The PLAIN SASL Mechanism August 2006
515+
516+
517+ Appendix A. Changes since RFC 2595
518+
519+ This appendix is non-normative.
520+
521+ This document replaces Section 6 of RFC 2595.
522+
523+ The specification details how the server is to compare client-
524+ provided character strings with stored character strings.
525+
526+ The ABNF grammar was updated. In particular, the grammar now allows
527+ LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the
528+ authzid, authcid, passwd productions. However, whether these control
529+ characters may be used depends on the string preparation rules
530+ applicable to the production. For passwd and authcid productions,
531+ control characters are prohibited. For authzid, one must consult the
532+ application-level SASL profile. This change allows PLAIN to carry
533+ all possible authorization identity strings allowed in SASL.
534+
535+ Pseudo-code was added.
536+
537+ The example section was expanded to illustrate more features of the
538+ PLAIN mechanism.
539+
540+ Editor's Address
541+
542+ Kurt D. Zeilenga
543+ OpenLDAP Foundation
544+
545+ EMail: Kurt@OpenLDAP.org
546+
547+
548+
549+
550+
551+
552+
553+
554+
555+
556+
557+
558+
559+
560+
561+
562+
563+
564+
565+
566+
567+
568+ Zeilenga Standards Track [Page 10]
569+
570+ RFC 4616 The PLAIN SASL Mechanism August 2006
571+
572+
573+ Full Copyright Statement
574+
575+ Copyright (C) The Internet Society (2006).
576+
577+ This document is subject to the rights, licenses and restrictions
578+ contained in BCP 78, and except as set forth therein, the authors
579+ retain all their rights.
580+
581+ This document and the information contained herein are provided on an
582+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
583+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
584+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
585+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
586+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
587+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
588+
589+ Intellectual Property
590+
591+ The IETF takes no position regarding the validity or scope of any
592+ Intellectual Property Rights or other rights that might be claimed to
593+ pertain to the implementation or use of the technology described in
594+ this document or the extent to which any license under such rights
595+ might or might not be available; nor does it represent that it has
596+ made any independent effort to identify any such rights. Information
597+ on the procedures with respect to rights in RFC documents can be
598+ found in BCP 78 and BCP 79.
599+
600+ Copies of IPR disclosures made to the IETF Secretariat and any
601+ assurances of licenses to be made available, or the result of an
602+ attempt made to obtain a general license or permission for the use of
603+ such proprietary rights by implementers or users of this
604+ specification can be obtained from the IETF on-line IPR repository at
605+ http://www.ietf.org/ipr.
606+
607+ The IETF invites any interested party to bring to its attention any
608+ copyrights, patents or patent applications, or other proprietary
609+ rights that may cover technology that may be required to implement
610+ this standard. Please address the information to the IETF at
611+ ietf-ipr@ietf.org.
612+
613+ Acknowledgement
614+
615+ Funding for the RFC Editor function is provided by the IETF
616+ Administrative Support Activity (IASA).
617+
618+
619+
620+
621+
622+
623+
624+ Zeilenga Standards Track [Page 11]
625+
626 diff --git a/rfcs/rfc4954.txt b/rfcs/rfc4954.txt
627new file mode 100644
628index 0000000..668d738
629--- /dev/null
630+++ b/rfcs/rfc4954.txt
631 @@ -0,0 +1,1123 @@
632+
633+
634+
635+
636+
637+
638+ Network Working Group R. Siemborski, Ed.
639+ Request for Comments: 4954 Google, Inc.
640+ Obsoletes: 2554 A. Melnikov, Ed.
641+ Updates: 3463 Isode Limited
642+ Category: Standards Track July 2007
643+
644+
645+ SMTP Service Extension for Authentication
646+
647+ Status of This Memo
648+
649+ This document specifies an Internet standards track protocol for the
650+ Internet community, and requests discussion and suggestions for
651+ improvements. Please refer to the current edition of the "Internet
652+ Official Protocol Standards" (STD 1) for the standardization state
653+ and status of this protocol. Distribution of this memo is unlimited.
654+
655+ Copyright Notice
656+
657+ Copyright (C) The IETF Trust (2007).
658+
659+ Abstract
660+
661+ This document defines a Simple Mail Transport Protocol (SMTP)
662+ extension whereby an SMTP client may indicate an authentication
663+ mechanism to the server, perform an authentication protocol exchange,
664+ and optionally negotiate a security layer for subsequent protocol
665+ interactions during this session. This extension includes a profile
666+ of the Simple Authentication and Security Layer (SASL) for SMTP.
667+
668+ This document obsoletes RFC 2554.
669+
670+
671+
672+
673+
674+
675+
676+
677+
678+
679+
680+
681+
682+
683+
684+
685+
686+
687+
688+
689+ Siemborski & Melnikov Standards Track [Page 1]
690+
691+ RFC 4954 SMTP Service Extension for Authentication July 2007
692+
693+
694+ Table of Contents
695+
696+ 1. Introduction ....................................................2
697+ 2. How to Read This Document .......................................2
698+ 3. The Authentication Service Extension ............................3
699+ 4. The AUTH Command ................................................3
700+ 4.1. Examples ...................................................7
701+ 5. The AUTH Parameter to the MAIL FROM command .....................9
702+ 5.1. Examples ..................................................10
703+ 6. Status Codes ...................................................11
704+ 7. Additional requirements on servers .............................12
705+ 8. Formal Syntax ..................................................13
706+ 9. Security Considerations ........................................14
707+ 10. IANA Considerations ...........................................15
708+ 11. Normative References ..........................................15
709+ 12. Informative References ........................................16
710+ 13. Acknowledgments ...............................................17
711+ 14. Additional Requirements When Using SASL PLAIN over TLS ........17
712+ 15. Changes since RFC 2554 ........................................18
713+
714+ 1. Introduction
715+
716+ This document defines a Simple Mail Transport Protocol (SMTP)
717+ extension whereby an SMTP client may indicate an authentication
718+ mechanism to the server, perform an authentication protocol exchange,
719+ optionally negotiate a security layer for subsequent protocol
720+ interactions during this session and, during a mail transaction,
721+ optionally specify a mailbox associated with the identity that
722+ submitted the message to the mail delivery system.
723+
724+ This extension includes a profile of the Simple Authentication and
725+ Security Layer (SASL) for SMTP.
726+
727+ When compared to RFC 2554, this document deprecates use of the 538
728+ response code, adds a new Enhanced Status Code, adds a requirement to
729+ support SASLprep profile for preparing authorization identities,
730+ recommends use of RFC 3848 transmission types in the Received trace
731+ header field, and clarifies interaction with SMTP PIPELINING
732+ [PIPELINING] extension.
733+
734+ 2. How to Read This Document
735+
736+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
737+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
738+ document are to be interpreted as described in [KEYWORDS].
739+
740+ In examples, "C:" and "S:" indicate lines sent by the client and
741+ server, respectively.
742+
743+
744+
745+ Siemborski & Melnikov Standards Track [Page 2]
746+
747+ RFC 4954 SMTP Service Extension for Authentication July 2007
748+
749+
750+ 3. The Authentication Service Extension
751+
752+ 1. The name of this [SMTP] service extension is "Authentication".
753+
754+ 2. The EHLO keyword value associated with this extension is "AUTH".
755+
756+ 3. The AUTH EHLO keyword contains as a parameter a space-separated
757+ list of the names of available [SASL] mechanisms. The list of
758+ available mechanisms MAY change after a successful STARTTLS
759+ command [SMTP-TLS].
760+
761+ 4. A new [SMTP] verb "AUTH" is defined.
762+
763+ 5. An optional parameter using the keyword "AUTH" is added to the
764+ MAIL FROM command, and extends the maximum line length of the
765+ MAIL FROM command by 500 characters.
766+
767+ 6. This extension is appropriate for the submission protocol
768+ [SUBMIT].
769+
770+ 4. The AUTH Command
771+
772+ AUTH mechanism [initial-response]
773+
774+ Arguments:
775+ mechanism: A string identifying a [SASL] authentication
776+ mechanism.
777+
778+ initial-response: An optional initial client response. If
779+ present, this response MUST be encoded as described in Section
780+ 4 of [BASE64] or contain a single character "=".
781+
782+ Restrictions:
783+ After an AUTH command has been successfully completed, no more
784+ AUTH commands may be issued in the same session. After a
785+ successful AUTH command completes, a server MUST reject any
786+ further AUTH commands with a 503 reply.
787+
788+ The AUTH command is not permitted during a mail transaction.
789+ An AUTH command issued during a mail transaction MUST be
790+ rejected with a 503 reply.
791+
792+ Discussion:
793+ The AUTH command initiates a [SASL] authentication exchange
794+ between the client and the server. The client identifies the
795+ SASL mechanism to use with the first parameter of the AUTH
796+ command. If the server supports the requested authentication
797+ mechanism, it performs the SASL exchange to authenticate the
798+
799+
800+
801+ Siemborski & Melnikov Standards Track [Page 3]
802+
803+ RFC 4954 SMTP Service Extension for Authentication July 2007
804+
805+
806+ user. Optionally, it also negotiates a security layer for
807+ subsequent protocol interactions during this session. If the
808+ requested authentication mechanism is invalid (e.g., is not
809+ supported or requires an encryption layer), the server rejects
810+ the AUTH command with a 504 reply. If the server supports the
811+ [ESMTP-CODES] extension, it SHOULD return a 5.5.4 enhanced
812+ response code.
813+
814+ The SASL authentication exchange consists of a series of
815+ server challenges and client responses that are specific to
816+ the chosen [SASL] mechanism.
817+
818+ A server challenge is sent as a 334 reply with the text part
819+ containing the [BASE64] encoded string supplied by the SASL
820+ mechanism. This challenge MUST NOT contain any text other
821+ than the BASE64 encoded challenge.
822+
823+ A client response consists of a line containing a [BASE64]
824+ encoded string. If the client wishes to cancel the
825+ authentication exchange, it issues a line with a single "*".
826+ If the server receives such a response, it MUST reject the
827+ AUTH command by sending a 501 reply.
828+
829+ The optional initial response argument to the AUTH command is
830+ used to save a round-trip when using authentication mechanisms
831+ that support an initial client response. If the initial
832+ response argument is omitted and the chosen mechanism requires
833+ an initial client response, the server MUST proceed as defined
834+ in Section 5.1 of [SASL]. In SMTP, a server challenge that
835+ contains no data is defined as a 334 reply with no text part.
836+ Note that there is still a space following the reply code, so
837+ the complete response line is "334 ".
838+
839+ Note that the AUTH command is still subject to the line length
840+ limitations defined in [SMTP]. If use of the initial response
841+ argument would cause the AUTH command to exceed this length,
842+ the client MUST NOT use the initial response parameter (and
843+ instead proceed as defined in Section 5.1 of [SASL]).
844+
845+ If the client is transmitting an initial response of zero
846+ length, it MUST instead transmit the response as a single
847+ equals sign ("="). This indicates that the response is
848+ present, but contains no data.
849+
850+ If the client uses an initial-response argument to the AUTH
851+ command with a SASL mechanism in which the client does not
852+ begin the authentication exchange, the server MUST reject the
853+
854+
855+
856+
857+ Siemborski & Melnikov Standards Track [Page 4]
858+
859+ RFC 4954 SMTP Service Extension for Authentication July 2007
860+
861+
862+ AUTH command with a 501 reply. Servers using the enhanced
863+ status codes extension [ESMTP-CODES] SHOULD return an enhanced
864+ status code of 5.7.0 in this case.
865+
866+ If the server cannot [BASE64] decode any client response, it
867+ MUST reject the AUTH command with a 501 reply (and an enhanced
868+ status code of 5.5.2). If the client cannot BASE64 decode any
869+ of the server's challenges, it MUST cancel the authentication
870+ using the "*" response. In particular, servers and clients
871+ MUST reject (and not ignore) any character not explicitly
872+ allowed by the BASE64 alphabet, and MUST reject any sequence
873+ of BASE64 characters that contains the pad character ('=')
874+ anywhere other than the end of the string (e.g., "=AAA" and
875+ "AAA=BBB" are not allowed).
876+
877+ Note that these [BASE64] strings can be much longer than
878+ normal SMTP commands. Clients and servers MUST be able to
879+ handle the maximum encoded size of challenges and responses
880+ generated by their supported authentication mechanisms. This
881+ requirement is independent of any line length limitations the
882+ client or server may have in other parts of its protocol
883+ implementation. (At the time of writing of this document,
884+ 12288 octets is considered to be a sufficient line length
885+ limit for handling of deployed authentication mechanisms.)
886+ If, during an authentication exchange, the server receives a
887+ line that is longer than the server's authentication buffer,
888+ the server fails the AUTH command with the 500 reply. Servers
889+ using the enhanced status codes extension [ESMTP-CODES] SHOULD
890+ return an enhanced status code of 5.5.6 in this case.
891+
892+ The authorization identity generated by this [SASL] exchange
893+ is a "simple username" (in the sense defined in [SASLprep]),
894+ and both client and server SHOULD (*) use the [SASLprep]
895+ profile of the [StringPrep] algorithm to prepare these names
896+ for transmission or comparison. If preparation of the
897+ authorization identity fails or results in an empty string
898+ (unless it was transmitted as the empty string), the server
899+ MUST fail the authentication.
900+
901+ (*) Note: Future revision of this specification may change this
902+ requirement to MUST. Currently, the SHOULD is used in order to
903+ avoid breaking the majority of existing implementations.
904+
905+ If the server is unable to authenticate the client, it SHOULD reject
906+ the AUTH command with a 535 reply unless a more specific error code
907+ is appropriate. Should the client successfully complete the
908+ exchange, the SMTP server issues a 235 reply. (Note that the SMTP
909+ protocol doesn't support the SASL feature of returning additional
910+
911+
912+
913+ Siemborski & Melnikov Standards Track [Page 5]
914+
915+ RFC 4954 SMTP Service Extension for Authentication July 2007
916+
917+
918+ data with a successful outcome.) These status codes, along with
919+ others defined by this extension, are discussed in Section 6 of this
920+ document.
921+
922+ If a security layer is negotiated during the SASL exchange, it takes
923+ effect for the client on the octet immediately following the CRLF
924+ that concludes the last response generated by the client. For the
925+ server, it takes effect immediately following the CRLF of its success
926+ reply.
927+
928+ When a security layer takes effect, the SMTP protocol is reset to the
929+ initial state (the state in SMTP after a server issues a 220 service
930+ ready greeting). The server MUST discard any knowledge obtained from
931+ the client, such as the EHLO argument, which was not obtained from
932+ the SASL negotiation itself. Likewise, the client MUST discard any
933+ knowledge obtained from the server, such as the list of SMTP service
934+ extensions, which was not obtained from the SASL negotiation itself.
935+ (Note that a client MAY compare the advertised SASL mechanisms before
936+ and after authentication in order to detect an active down-
937+ negotiation attack).
938+
939+ The client SHOULD send an EHLO command as the first command after a
940+ successful SASL negotiation that results in the enabling of a
941+ security layer.
942+
943+ When an entity (whether it is the client or the server end) is
944+ sending data, and both [TLS] and SASL security layers are in effect,
945+ the TLS encoding MUST be applied after the SASL encoding, regardless
946+ of the order in which the layers were negotiated.
947+
948+ The service name specified by this protocol's profile of SASL is
949+ "smtp". This service name is also to be used for the [SUBMIT]
950+ protocol.
951+
952+ If an AUTH command fails, the client MAY proceed without
953+ authentication. Alternatively, the client MAY try another
954+ authentication mechanism or present different credentials by issuing
955+ another AUTH
956+
957+ Note: A server implementation MUST implement a configuration in which
958+ it does NOT permit any plaintext password mechanisms, unless either
959+ the STARTTLS [SMTP-TLS] command has been negotiated or some other
960+ mechanism that protects the session from password snooping has been
961+ provided. Server sites SHOULD NOT use any configuration which
962+ permits a plaintext password mechanism without such a protection
963+ mechanism against password snooping.
964+
965+
966+
967+
968+
969+ Siemborski & Melnikov Standards Track [Page 6]
970+
971+ RFC 4954 SMTP Service Extension for Authentication July 2007
972+
973+
974+ To ensure interoperability, client and server implementations of this
975+ extension MUST implement the [PLAIN] SASL mechanism running over TLS
976+ [TLS] [SMTP-TLS]. See also Section 15 for additional requirements on
977+ implementations of [PLAIN] over [TLS].
978+
979+ Note that many existing client and server implementations implement
980+ CRAM-MD5 [CRAM-MD5] SASL mechanism. In order to ensure
981+ interoperability with deployed software, new implementations MAY
982+ implement it; however, implementations should be aware that this SASL
983+ mechanism doesn't provide any server authentication. Note that at
984+ the time of writing of this document the SASL Working Group is
985+ working on several replacement SASL mechanisms that provide server
986+ authentication and other features.
987+
988+ When the AUTH command is used together with the [PIPELINING]
989+ extension, it MUST be the last command in a pipelined group of
990+ commands. The only exception to this rule is when the AUTH command
991+ contains an initial response for a SASL mechanism that allows the
992+ client to send data first, the SASL mechanism is known to complete in
993+ one round-trip, and a security layer is not negotiated by the client.
994+ Two examples of such SASL mechanisms are PLAIN [PLAIN] and EXTERNAL
995+ [SASL].
996+
997+ 4.1. Examples
998+
999+ Here is an example of a client attempting AUTH using the [PLAIN] SASL
1000+ mechanism under a TLS layer, and making use of the initial client
1001+ response:
1002+
1003+ S: 220-smtp.example.com ESMTP Server
1004+ C: EHLO client.example.com
1005+ S: 250-smtp.example.com Hello client.example.com
1006+ S: 250-AUTH GSSAPI DIGEST-MD5
1007+ S: 250-ENHANCEDSTATUSCODES
1008+ S: 250 STARTTLS
1009+ C: STARTTLS
1010+ S: 220 Ready to start TLS
1011+ ... TLS negotiation proceeds, further commands
1012+ protected by TLS layer ...
1013+ C: EHLO client.example.com
1014+ S: 250-smtp.example.com Hello client.example.com
1015+ S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN
1016+ C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ=
1017+ S: 235 2.7.0 Authentication successful
1018+
1019+ Here is another client that is attempting AUTH PLAIN under a TLS
1020+ layer, this time without the initial response. Parts of the
1021+ negotiation before the TLS layer was established have been omitted:
1022+
1023+
1024+
1025+ Siemborski & Melnikov Standards Track [Page 7]
1026+
1027+ RFC 4954 SMTP Service Extension for Authentication July 2007
1028+
1029+
1030+ ... TLS negotiation proceeds, further commands
1031+ protected by TLS layer ...
1032+ C: EHLO client.example.com
1033+ S: 250-smtp.example.com Hello client.example.com
1034+ S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN
1035+ C: AUTH PLAIN
1036+ (note: there is a single space following the 334
1037+ on the following line)
1038+ S: 334
1039+ C: dGVzdAB0ZXN0ADEyMzQ=
1040+ S: 235 2.7.0 Authentication successful
1041+
1042+ Here is an example using CRAM-MD5 [CRAM-MD5], a mechanism in which
1043+ the client does not begin the authentication exchange, and includes a
1044+ server challenge:
1045+
1046+ S: 220-smtp.example.com ESMTP Server
1047+ C: EHLO client.example.com
1048+ S: 250-smtp.example.com Hello client.example.com
1049+ S: 250-AUTH DIGEST-MD5 CRAM-MD5
1050+ S: 250-ENHANCEDSTATUSCODES
1051+ S: 250 STARTTLS
1052+ C: AUTH CRAM-MD5
1053+ S: 334 PDQxOTI5NDIzNDEuMTI4Mjg0NzJAc291cmNlZm91ci5hbmRyZXcuY211LmVk
1054+ dT4=
1055+ C: cmpzMyBlYzNhNTlmZWQzOTVhYmExZWM2MzY3YzRmNGI0MWFjMA==
1056+ S: 235 2.7.0 Authentication successful
1057+
1058+ Here is an example of a client attempting AUTH EXTERNAL under TLS,
1059+ using the derived authorization ID (and thus a zero-length initial
1060+ client response).
1061+
1062+ S: 220-smtp.example.com ESMTP Server
1063+ C: EHLO client.example.com
1064+ S: 250-smtp.example.com Hello client.example.com
1065+ S: 250-AUTH GSSAPI DIGEST-MD5
1066+ S: 250-ENHANCEDSTATUSCODES
1067+ S: 250 STARTTLS
1068+ C: STARTTLS
1069+ S: 220 Ready to start TLS
1070+ ... TLS negotiation proceeds, further commands
1071+ protected by TLS layer ...
1072+ C: EHLO client.example.com
1073+ S: 250-smtp.example.com Hello client.example.com
1074+ S: 250 AUTH EXTERNAL GSSAPI DIGEST-MD5 PLAIN
1075+ C: AUTH EXTERNAL =
1076+ S: 235 2.7.0 Authentication successful
1077+
1078+
1079+
1080+
1081+ Siemborski & Melnikov Standards Track [Page 8]
1082+
1083+ RFC 4954 SMTP Service Extension for Authentication July 2007
1084+
1085+
1086+ 5. The AUTH Parameter to the MAIL FROM command
1087+
1088+ AUTH=mailbox
1089+
1090+ Arguments:
1091+ A <mailbox> (see Section 4.1.2 of [SMTP]) that is associated
1092+ with the identity that submitted the message to the delivery
1093+ system, or the two character sequence "<>" indicating such an
1094+ identity is unknown or insufficiently authenticated. To comply
1095+ with restrictions imposed on ESMTP parameters, the <mailbox> is
1096+ encoded inside an xtext. The syntax of an xtext is described in
1097+ Section 4 of [ESMTP-DSN].
1098+
1099+ Note:
1100+ For the purposes of this discussion, "authenticated identity"
1101+ refers to the identity (if any) derived from the authorization
1102+ identity of previous AUTH command, while the terms "authorized
1103+ identity" and "supplied <mailbox>" refer to the sender identity
1104+ that is being associated with a particular message. Note that
1105+ one authenticated identity may be able to identify messages as
1106+ being sent by any number of authorized identities within a
1107+ single session. For example, this may be the case when an SMTP
1108+ server (one authenticated identity) is processing its queue
1109+ (many messages with distinct authorized identities).
1110+
1111+ Discussion:
1112+ The optional AUTH parameter to the MAIL FROM command allows
1113+ cooperating agents in a trusted environment to communicate the
1114+ authorization identity associated with individual messages.
1115+
1116+ If the server trusts the authenticated identity of the client to
1117+ assert that the message was originally submitted by the supplied
1118+ <mailbox>, then the server SHOULD supply the same <mailbox> in
1119+ an AUTH parameter when relaying the message to any other server
1120+ which supports the AUTH extension.
1121+
1122+ For this reason, servers that advertise support for this
1123+ extension MUST support the AUTH parameter to the MAIL FROM
1124+ command even when the client has not authenticated itself to the
1125+ server.
1126+
1127+ A MAIL FROM parameter of AUTH=<> indicates that the original
1128+ submitter of the message is not known. The server MUST NOT
1129+ treat the message as having been originally submitted by the
1130+ authenticated identity that resulted from the AUTH command.
1131+
1132+
1133+
1134+
1135+
1136+
1137+ Siemborski & Melnikov Standards Track [Page 9]
1138+
1139+ RFC 4954 SMTP Service Extension for Authentication July 2007
1140+
1141+
1142+ If the AUTH parameter to the MAIL FROM command is not supplied,
1143+ the client has authenticated, and the server believes the
1144+ message is an original submission, the server MAY generate a
1145+ <mailbox> from the user's authenticated identity for use in an
1146+ AUTH parameter when relaying the message to any server which
1147+ supports the AUTH extension. The generated <mailbox> is
1148+ implementation specific, but it MUST conform to the syntax of
1149+ [SMTP]. If the implementation cannot generate a valid
1150+ <mailbox>, it MUST transmit AUTH=<> when relaying this message.
1151+
1152+ If the server does not sufficiently trust the authenticated
1153+ identity of the client, or if the client is not authenticated,
1154+ then the server MUST behave as if the AUTH=<> parameter was
1155+ supplied. The server MAY, however, write the value of any
1156+ supplied AUTH parameter to a log file.
1157+
1158+ If an AUTH=<> parameter was supplied, either explicitly or due
1159+ to the requirement in the previous paragraph, then the server
1160+ MUST supply the AUTH=<> parameter when relaying the message to
1161+ any server which it has authenticated to using the AUTH
1162+ extension.
1163+
1164+ A server MAY treat expansion of a mailing list as a new
1165+ submission, setting the AUTH parameter to the mailing list
1166+ address or mailing list administration address when relaying the
1167+ message to list subscribers.
1168+
1169+ Note that an implementation which is hard-coded to treat all
1170+ clients as being insufficiently trusted is compliant with this
1171+ specification. In that case, the implementation does nothing
1172+ more than parse and discard syntactically valid AUTH parameters
1173+ to the MAIL FROM command, and supply AUTH=<> parameters to any
1174+ servers that it authenticates to.
1175+
1176+ 5.1. Examples
1177+
1178+ An example where the original identity of the sender is trusted and
1179+ known:
1180+
1181+ C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com
1182+ S: 250 OK
1183+
1184+ One example where the identity of the sender is not trusted or is
1185+ otherwise being suppressed by the client:
1186+
1187+ C: MAIL FROM:<john+@example.org> AUTH=<>
1188+ S: 250 OK
1189+
1190+
1191+
1192+
1193+ Siemborski & Melnikov Standards Track [Page 10]
1194+
1195+ RFC 4954 SMTP Service Extension for Authentication July 2007
1196+
1197+
1198+ 6. Status Codes
1199+
1200+ The following error codes may be used to indicate various success or
1201+ failure conditions. Servers that return enhanced status codes
1202+ [ESMTP-CODES] SHOULD use the enhanced codes suggested here.
1203+
1204+ 235 2.7.0 Authentication Succeeded
1205+
1206+ This response to the AUTH command indicates that the authentication
1207+ was successful.
1208+
1209+ 432 4.7.12 A password transition is needed
1210+
1211+ This response to the AUTH command indicates that the user needs to
1212+ transition to the selected authentication mechanism. This is
1213+ typically done by authenticating once using the [PLAIN]
1214+ authentication mechanism. The selected mechanism SHOULD then work
1215+ for authentications in subsequent sessions.
1216+
1217+ 454 4.7.0 Temporary authentication failure
1218+
1219+ This response to the AUTH command indicates that the authentication
1220+ failed due to a temporary server failure. The client SHOULD NOT
1221+ prompt the user for another password in this case, and should instead
1222+ notify the user of server failure.
1223+
1224+ 534 5.7.9 Authentication mechanism is too weak
1225+
1226+ This response to the AUTH command indicates that the selected
1227+ authentication mechanism is weaker than server policy permits for
1228+ that user. The client SHOULD retry with a new authentication
1229+ mechanism.
1230+
1231+ 535 5.7.8 Authentication credentials invalid
1232+
1233+ This response to the AUTH command indicates that the authentication
1234+ failed due to invalid or insufficient authentication credentials. In
1235+ this case, the client SHOULD ask the user to supply new credentials
1236+ (such as by presenting a password dialog box).
1237+
1238+ 500 5.5.6 Authentication Exchange line is too long
1239+
1240+ This response to the AUTH command indicates that the authentication
1241+ failed due to the client sending a [BASE64] response that is longer
1242+ than the maximum buffer size available for the currently selected
1243+ SASL mechanism.
1244+
1245+
1246+
1247+
1248+
1249+ Siemborski & Melnikov Standards Track [Page 11]
1250+
1251+ RFC 4954 SMTP Service Extension for Authentication July 2007
1252+
1253+
1254+ 530 5.7.0 Authentication required
1255+
1256+ This response SHOULD be returned by any command other than AUTH,
1257+ EHLO, HELO, NOOP, RSET, or QUIT when server policy requires
1258+ authentication in order to perform the requested action and
1259+ authentication is not currently in force.
1260+
1261+ 538 5.7.11 Encryption required for requested authentication
1262+ mechanism
1263+
1264+ This response to the AUTH command indicates that the selected
1265+ authentication mechanism may only be used when the underlying SMTP
1266+ connection is encrypted. Note that this response code is documented
1267+ here for historical purposes only. Modern implementations SHOULD NOT
1268+ advertise mechanisms that are not permitted due to lack of
1269+ encryption, unless an encryption layer of sufficient strength is
1270+ currently being employed.
1271+
1272+ This document adds several new enhanced status codes to the list
1273+ defined in [ENHANCED]:
1274+
1275+ The following 3 Enhanced Status Codes were defined above:
1276+
1277+ 5.7.8 Authentication credentials invalid
1278+ 5.7.9 Authentication mechanism is too weak
1279+ 5.7.11 Encryption required for requested authentication mechanism
1280+
1281+ X.5.6 Authentication Exchange line is too long
1282+
1283+ This enhanced status code SHOULD be returned when the server fails
1284+ the AUTH command due to the client sending a [BASE64] response which
1285+ is longer than the maximum buffer size available for the currently
1286+ selected SASL mechanism. This is useful for both permanent and
1287+ persistent transient errors.
1288+
1289+ 7. Additional Requirements on Servers
1290+
1291+ As described in Section 4.4 of [SMTP], an SMTP server that receives a
1292+ message for delivery or further processing MUST insert the
1293+ "Received:" header field at the beginning of the message content.
1294+ This document places additional requirements on the content of a
1295+ generated "Received:" header field. Upon successful authentication,
1296+ a server SHOULD use the "ESMTPA" or the "ESMTPSA" [SMTP-TT] (when
1297+ appropriate) keyword in the "with" clause of the Received header
1298+ field.
1299+
1300+
1301+
1302+
1303+
1304+
1305+ Siemborski & Melnikov Standards Track [Page 12]
1306+
1307+ RFC 4954 SMTP Service Extension for Authentication July 2007
1308+
1309+
1310+ 8. Formal Syntax
1311+
1312+ The following syntax specification uses the Augmented Backus-Naur
1313+ Form notation as specified in [ABNF]. Non-terminals referenced but
1314+ not defined below are as defined by [ABNF] or [SASL]. The non-
1315+ terminal <mailbox> is defined in [SMTP].
1316+
1317+ Except as noted otherwise, all alphabetic characters are case-
1318+ insensitive. The use of upper or lower case characters to define
1319+ token strings is for editorial clarity only. Implementations MUST
1320+ accept these strings in a case-insensitive fashion.
1321+
1322+ hexchar = "+" HEXDIG HEXDIG
1323+
1324+ xchar = %x21-2A / %x2C-3C / %x3E-7E
1325+ ;; US-ASCII except for "+", "=", SP, and CTL
1326+
1327+ xtext = *(xchar / hexchar)
1328+ ;; non-US-ASCII is only allowed as hexchar
1329+
1330+ auth-command = "AUTH" SP sasl-mech [SP initial-response]
1331+ *(CRLF [base64]) [CRLF cancel-response]
1332+ CRLF
1333+ ;; <sasl-mech> is defined in [SASL]
1334+
1335+ auth-param = "AUTH=" xtext
1336+ ;; Parameter to the MAIL FROM command.
1337+ ;; This non-terminal complies with
1338+ ;; syntax defined by esmtp-param [SMTP].
1339+ ;;
1340+ ;; The decoded form of the xtext MUST be
1341+ ;; either a <mailbox> or the two
1342+ ;; characters "<>"
1343+
1344+ base64 = base64-terminal /
1345+ ( 1*(4base64-char) [base64-terminal] )
1346+
1347+ base64-char = ALPHA / DIGIT / "+" / "/"
1348+ ;; Case-sensitive
1349+
1350+ base64-terminal = (2base64-char "==") / (3base64-char "=")
1351+
1352+ continue-req = "334" SP [base64] CRLF
1353+ ;; Intermediate response to the AUTH
1354+ ;; command.
1355+ ;; This non-terminal complies with
1356+ ;; syntax defined by Reply-line [SMTP].
1357+
1358+
1359+
1360+
1361+ Siemborski & Melnikov Standards Track [Page 13]
1362+
1363+ RFC 4954 SMTP Service Extension for Authentication July 2007
1364+
1365+
1366+ initial-response= base64 / "="
1367+
1368+ cancel-response = "*"
1369+
1370+ 9. Security Considerations
1371+
1372+ Security issues are discussed throughout this memo.
1373+
1374+ If a client uses this extension to get an encrypted tunnel through an
1375+ insecure network to a cooperating server, it needs to be configured
1376+ to never send mail to that server when the connection is not mutually
1377+ authenticated and encrypted. Otherwise, an attacker could steal the
1378+ client's mail by hijacking the [SMTP] connection and either
1379+ pretending the server does not support the Authentication extension
1380+ or causing all AUTH commands to fail.
1381+
1382+ Before the [SASL] negotiation has begun, any protocol interactions
1383+ are performed in the clear and may be modified by an active attacker.
1384+ For this reason, clients and servers MUST discard any knowledge
1385+ obtained prior to the start of the SASL negotiation upon the
1386+ establishment of a security layer.
1387+
1388+ This mechanism does not protect the TCP port, so an active attacker
1389+ may redirect a relay connection attempt (i.e., a connection between
1390+ two Mail Transfer Agents (MTAs)) to the submission port [SUBMIT].
1391+ The AUTH=<> parameter prevents such an attack from causing a relayed
1392+ message and, in the absence of other envelope authentication, from
1393+ picking up the authentication of the relay client.
1394+
1395+ A message submission client may require the user to authenticate
1396+ whenever a suitable [SASL] mechanism is advertised. Therefore, it
1397+ may not be desirable for a submission server [SUBMIT] to advertise a
1398+ SASL mechanism when use of that mechanism grants the clients no
1399+ benefits over anonymous submission.
1400+
1401+ Servers MAY implement a policy whereby the connection is dropped
1402+ after a number of failed authentication attempts. If they do so,
1403+ they SHOULD NOT drop the connection until at least 3 attempts to
1404+ authenticate have failed.
1405+
1406+ If an implementation supports SASL mechanisms that are vulnerable to
1407+ passive eavesdropping attacks (such as [PLAIN]), then the
1408+ implementation MUST support at least one configuration where these
1409+ SASL mechanisms are not advertised or used without the presence of an
1410+ external security layer such as [TLS].
1411+
1412+
1413+
1414+
1415+
1416+
1417+ Siemborski & Melnikov Standards Track [Page 14]
1418+
1419+ RFC 4954 SMTP Service Extension for Authentication July 2007
1420+
1421+
1422+ This extension is not intended to replace or be used instead of end-
1423+ to-end message signature and encryption systems such as [S/MIME] or
1424+ [PGP]. This extension addresses a different problem than end-to-end
1425+ systems; it has the following key differences:
1426+
1427+ 1. It is generally useful only within a trusted enclave.
1428+
1429+ 2. It protects the entire envelope of a message, not just the
1430+ message's body.
1431+
1432+ 3. It authenticates the message submission, not authorship of the
1433+ message content.
1434+
1435+ 4. When mutual authentication is used along with a security layer,
1436+ it can give the sender some assurance that the message was
1437+ successfully delivered to the next hop.
1438+
1439+ Additional security considerations are mentioned in the [SASL]
1440+ specification. Additional security considerations specific to a
1441+ particular SASL mechanism are described in the relevant
1442+ specification. Additional security considerations for [PLAIN] over
1443+ [TLS] are mentioned in Section 15 of this document.
1444+
1445+ 10. IANA Considerations
1446+
1447+ IANA updated the entry for the "smtp" SASL protocol name to point at
1448+ this document.
1449+
1450+ IANA updated the registration of the Authentication SMTP service
1451+ extension as defined in Section 3 of this document. This registry is
1452+ currently located at <http://www.iana.org/assignments/mail-
1453+ parameters>.
1454+
1455+ 11. Normative References
1456+
1457+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
1458+ Specifications: ABNF", RFC 4234, October 2005.
1459+
1460+ [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
1461+ Encodings", RFC 4648, October 2006.
1462+
1463+ [ESMTP-CODES] Freed, N., "SMTP Service Extension for Returning
1464+ Enhanced Error Codes", RFC 2034, October 1996.
1465+
1466+ [ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
1467+ 3463, January 2003.
1468+
1469+
1470+
1471+
1472+
1473+ Siemborski & Melnikov Standards Track [Page 15]
1474+
1475+ RFC 4954 SMTP Service Extension for Authentication July 2007
1476+
1477+
1478+ [ESMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP)
1479+ Service Extension Delivery Status Notifications
1480+ (DSNs)", RFC 3461, January 2003.
1481+
1482+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
1483+ Requirement Levels", BCP 14, RFC 2119, March 1997.
1484+
1485+ [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication
1486+ and Security Layer (SASL)", RFC 4422, June 2006.
1487+
1488+ [SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User
1489+ Names and Passwords", RFC 4013, February 2005.
1490+
1491+ [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
1492+ April 2001.
1493+
1494+ [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP
1495+ over Transport Layer Security", RFC 3207, February
1496+ 2002.
1497+
1498+ [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
1499+ Internationalized Strings ("stringprep")", RFC 3454,
1500+ December 2002.
1501+
1502+ [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for
1503+ Mail", RFC 4409, April 2006.
1504+
1505+ [SMTP-TT] Newman, C., "ESMTP and LMTP Transmission Types
1506+ Registration", RFC 3848, July 2004.
1507+
1508+ [PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and
1509+ Security Layer (SASL) Mechanism", RFC 4616, August
1510+ 2006.
1511+
1512+ [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
1513+ X.509 Public Key Infrastructure Certificate and
1514+ Certificate Revocation List (CRL) Profile", RFC 3280,
1515+ April 2002.
1516+
1517+ 12. Informative References
1518+
1519+ [PGP] Elkins, M., "MIME Security with Pretty Good Privacy
1520+ (PGP)", RFC 2015, October 1996.
1521+
1522+ [S/MIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
1523+ Extensions (S/MIME) Version 3.1 Message Specification",
1524+ RFC 3851, July 2004.
1525+
1526+
1527+
1528+
1529+ Siemborski & Melnikov Standards Track [Page 16]
1530+
1531+ RFC 4954 SMTP Service Extension for Authentication July 2007
1532+
1533+
1534+ [TLS] Dierks, T. and E. Rescorla, "The Transport Layer
1535+ Security (TLS) Protocol Version 1.1", RFC 4346, April
1536+ 2006.
1537+
1538+ [PIPELINING] Freed, N., "SMTP Service Extension for Command
1539+ Pipelining", STD 60, RFC 2920, September 2000.
1540+
1541+ [CRAM-MD5] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
1542+ AUTHorize Extension for Simple Challenge/Response", RFC
1543+ 2195, September 1997.
1544+
1545+ 13. Acknowledgments
1546+
1547+ The editors would like to acknowledge the contributions of John Myers
1548+ and other contributors to RFC 2554, on which this document draws from
1549+ heavily.
1550+
1551+ The editors would also like to thank Ken Murchison, Mark Crispin,
1552+ Chris Newman, David Wilson, Dave Cridland, Frank Ellermann, Ned
1553+ Freed, John Klensin, Tony Finch, Abhijit Menon-Sen, Philip Guenther,
1554+ Sam Hartman, Russ Housley, Cullen Jennings, and Lisa Dusseault for
1555+ the time they devoted to reviewing of this document and/or for the
1556+ comments received.
1557+
1558+ 14. Additional Requirements When Using SASL PLAIN over TLS
1559+
1560+ This section is normative for SMTP implementations that support SASL
1561+ [PLAIN] over [TLS].
1562+
1563+ If an SMTP client is willing to use SASL PLAIN over TLS to
1564+ authenticate to the SMTP server, the client verifies the server
1565+ certificate according to the rules of [X509]. If the server has not
1566+ provided any certificate, or if the certificate verification fails,
1567+ the client MUST NOT attempt to authenticate using the SASL PLAIN
1568+ mechanism.
1569+
1570+ After a successful [TLS] negotiation, the client MUST check its
1571+ understanding of the server hostname against the server's identity as
1572+ presented in the server Certificate message, in order to prevent
1573+ man-in-the-middle attacks. If the match fails, the client MUST NOT
1574+ attempt to authenticate using the SASL PLAIN mechanism. Matching is
1575+ performed according to the following rules:
1576+
1577+ The client MUST use the server hostname it used to open the
1578+ connection as the value to compare against the server name as
1579+ expressed in the server certificate. The client MUST NOT use
1580+
1581+
1582+
1583+
1584+
1585+ Siemborski & Melnikov Standards Track [Page 17]
1586+
1587+ RFC 4954 SMTP Service Extension for Authentication July 2007
1588+
1589+
1590+ any form of the server hostname derived from an insecure remote
1591+ source (e.g., insecure DNS lookup). CNAME canonicalization is
1592+ not done.
1593+
1594+ If a subjectAltName extension of type dNSName is present in the
1595+ certificate, it SHOULD be used as the source of the server's
1596+ identity.
1597+
1598+ Matching is case-insensitive.
1599+
1600+ A "*" wildcard character MAY be used as the leftmost name
1601+ component in the certificate. For example, *.example.com would
1602+ match a.example.com, foo.example.com, etc., but would not match
1603+ example.com.
1604+
1605+ If the certificate contains multiple names (e.g., more than one
1606+ dNSName field), then a match with any one of the fields is
1607+ considered acceptable.
1608+
1609+ 15. Changes since RFC 2554
1610+
1611+ 1. Clarified that servers MUST support the use of the AUTH=mailbox
1612+ parameter to MAIL FROM, even when the client is not
1613+ authenticated.
1614+
1615+ 2. Clarified the initial-client-send requirements, and give
1616+ additional examples.
1617+
1618+ 3. Updated references to newer versions of various specifications.
1619+
1620+ 4. Required SASL PLAIN (over TLS) as mandatory-to-implement.
1621+
1622+ 5. Clarified that the mechanism list can change.
1623+
1624+ 6. Deprecated the use of the 538 response code.
1625+
1626+ 7. Added the use of the SASLprep profile for preparing authorization
1627+ identities.
1628+
1629+ 8. Substantial cleanup of response codes and indicated suggested
1630+ enhanced response codes. Also indicated what response codes
1631+ should result in a client prompting the user for new credentials.
1632+
1633+ 9. Updated ABNF section to use RFC 4234.
1634+
1635+ 10. Clarified interaction with SMTP PIPELINING extension.
1636+
1637+ 11. Added a reference to RFC 3848.
1638+
1639+
1640+
1641+ Siemborski & Melnikov Standards Track [Page 18]
1642+
1643+ RFC 4954 SMTP Service Extension for Authentication July 2007
1644+
1645+
1646+ 12. Added a new Enhanced Status Code for "authentication line too
1647+ long" case.
1648+
1649+ 13. Other general editorial clarifications.
1650+
1651+ Editors' Addresses
1652+
1653+ Robert Siemborski
1654+ Google, Inc.
1655+ 1600 Ampitheatre Parkway
1656+ Mountain View, CA 94043, USA
1657+
1658+ Phone: +1 650 623 6925
1659+ EMail: robsiemb@google.com
1660+
1661+
1662+ Alexey Melnikov
1663+ Isode Limited
1664+ 5 Castle Business Village, 36 Station Road,
1665+ Hampton, Middlesex, TW12 2BX, UK
1666+
1667+ EMail: Alexey.Melnikov@isode.com
1668+
1669+
1670+
1671+
1672+
1673+
1674+
1675+
1676+
1677+
1678+
1679+
1680+
1681+
1682+
1683+
1684+
1685+
1686+
1687+
1688+
1689+
1690+
1691+
1692+
1693+
1694+
1695+
1696+
1697+ Siemborski & Melnikov Standards Track [Page 19]
1698+
1699+ RFC 4954 SMTP Service Extension for Authentication July 2007
1700+
1701+
1702+ Full Copyright Statement
1703+
1704+ Copyright (C) The IETF Trust (2007).
1705+
1706+ This document is subject to the rights, licenses and restrictions
1707+ contained in BCP 78, and except as set forth therein, the authors
1708+ retain all their rights.
1709+
1710+ This document and the information contained herein are provided on an
1711+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1712+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1713+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1714+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1715+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1716+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1717+
1718+ Intellectual Property
1719+
1720+ The IETF takes no position regarding the validity or scope of any
1721+ Intellectual Property Rights or other rights that might be claimed to
1722+ pertain to the implementation or use of the technology described in
1723+ this document or the extent to which any license under such rights
1724+ might or might not be available; nor does it represent that it has
1725+ made any independent effort to identify any such rights. Information
1726+ on the procedures with respect to rights in RFC documents can be
1727+ found in BCP 78 and BCP 79.
1728+
1729+ Copies of IPR disclosures made to the IETF Secretariat and any
1730+ assurances of licenses to be made available, or the result of an
1731+ attempt made to obtain a general license or permission for the use of
1732+ such proprietary rights by implementers or users of this
1733+ specification can be obtained from the IETF on-line IPR repository at
1734+ http://www.ietf.org/ipr.
1735+
1736+ The IETF invites any interested party to bring to its attention any
1737+ copyrights, patents or patent applications, or other proprietary
1738+ rights that may cover technology that may be required to implement
1739+ this standard. Please address the information to the IETF at
1740+ ietf-ipr@ietf.org.
1741+
1742+ Acknowledgement
1743+
1744+ Funding for the RFC Editor function is currently provided by the
1745+ Internet Society.
1746+
1747+
1748+
1749+
1750+
1751+
1752+
1753+ Siemborski & Melnikov Standards Track [Page 20]
1754+