idnits 2.17.1 draft-siemborski-rfc2554bis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 900. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 870. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 877. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 883. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3463, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3463, updated by this document, for RFC5378 checks: 2001-06-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2007) is 6221 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4013 (ref. 'SASLprep') (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 3454 (ref. 'StringPrep') (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4409 (ref. 'SUBMIT') (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 3280 (ref. 'X509') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Robert Siemborski 3 INTERNET-DRAFT Google, Inc. 4 Intended status: Standards Track Alexey Melnikov 5 Obsoletes: RFC 2554 (if approved) Isode Limited 6 Updates: RFC 3463 April 2007 7 Expires: October 2007 9 SMTP Service Extension for Authentication 10 12 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet 19 Engineering Task Force (IETF), its areas, and its 20 working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by 25 other documents at any time. It is inappropriate to use 26 Internet-Drafts as reference material or to cite them other 27 than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Distribution of this memo is unlimited. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines a Simple Mail Transport Protocol (SMTP) 44 extension whereby an SMTP client may indicate an authentication 45 mechanism to the server, perform an authentication protocol 46 exchange, and optionally negotiate a security layer for subsequent 47 protocol interactions during this session. This extension includes 48 a profile of the Simple Authentication and Security Layer (SASL) for 49 SMTP. 51 This document obsoletes RFC 2554. 53 1. Introduction 55 This document defines a Simple Mail Transport Protocol (SMTP) 56 extension whereby an SMTP client may indicate an authentication 57 mechanism to the server, perform an authentication protocol 58 exchange, optionally negotiate a security layer for subsequent 59 protocol interactions during this session and, during a mail 60 transaction, optionally specify a mailbox associated with the 61 identity which submitted the message to the mail delivery system. 63 This extension includes a profile of the Simple Authentication and 64 Security Layer (SASL) for SMTP. 66 When compared to RFC 2554, this document deprecates use of the 538 67 response code, adds a new Enhanced Status Code, adds a requirement 68 to support SASLprep profile for preparing authorization identities, 69 recommends use of RFC 3848 transmission types in the Received trace 70 header field, and clarifies interaction with SMTP PIPELINING 71 [PIPELINING] extension. 73 2. How to Read This Document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [KEYWORDS]. 79 In examples, "C:" and "S:" indicate lines sent by the client and 80 server, respectively. 82 3. The Authentication Service Extension 84 1. The name of this [SMTP] service extension is "Authentication" 86 2. The EHLO keyword value associated with this extension is 87 "AUTH" 89 3. The AUTH EHLO keyword contains as a parameter a space 90 separated list of the names of available [SASL] mechanisms. 91 The list of available mechanisms MAY change after a successful 92 STARTTLS command [SMTP-TLS]. 94 4. A new [SMTP] verb "AUTH" is defined. 96 5. An optional parameter using the keyword "AUTH" is added to the 97 MAIL FROM command, and extends the maximum line length of the 98 MAIL FROM command by 500 characters. 100 6. This extension is appropriate for the submission protocol 101 [SUBMIT]. 103 4. The AUTH Command 105 AUTH mechanism [initial-response] 107 Arguments: 108 mechanism: A string identifying a [SASL] authentication 109 mechanism. 111 initial-response: An optional initial client response. If 112 present, this response MUST be encoded as described in Section 113 4 of [BASE64] or contain a single character "=". 115 Restrictions: 116 After an AUTH command has been successfully completed, no more 117 AUTH commands may be issued in the same session. After a 118 successful AUTH command completes, a server MUST reject any 119 further AUTH commands with a 503 reply. 121 The AUTH command is not permitted during a mail transaction. 122 An AUTH command issued during a mail transaction MUST be 123 rejected with a 503 reply. 125 Discussion: 126 The AUTH command initiates a [SASL] authentication exchange 127 between the client and the server. The client identifies the 128 SASL mechanism to use with the first parameter of the AUTH 129 command. If the server supports the requested authentication 130 mechanism, it performs the SASL exchange to authenticate the 131 user. Optionally, it also negotiates a security layer for 132 subsequent protocol interactions during this session. If the 133 requested authentication mechanism is invalid (e.g. is not 134 supported or requires an encryption layer), the server rejects 135 the AUTH command with a 504 reply, and if it supports the 136 [ESMTP-CODES] extension it SHOULD return a 5.5.4 enhanced 137 response code. 139 The SASL authentication exchange consists of a series of 140 server challenges and client responses that are specific to 141 the chosen [SASL] mechanism. 143 A server challenge is sent as a 334 reply with the text part 144 containing the [BASE64] encoded string supplied by the SASL 145 mechanism. This challenge MUST NOT contain any text other 146 than the BASE64 encoded challenge. 148 A client response consists of a line containing a [BASE64] 149 encoded string. If the client wishes to cancel the 150 authentication exchange, it issues a line with a single "*". 151 If the server receives such a response, it MUST reject the 152 AUTH command by sending a 501 reply. 154 The optional initial response argument to the AUTH command is 155 used to save a round trip when using authentication mechanisms 156 that support an initial client response. If the initial 157 response argument is omitted and the chosen mechanism requires 158 an initial client response, the server MUST proceed as defined 159 in section 5.1 of [SASL]. In SMTP, a server challenge that 160 contains no data is defined as a 334 reply with no text part. 161 Note that there is still a space following the reply code, so 162 the complete response line is "334 ". 164 Note that the AUTH command is still subject to the line length 165 limitations defined in [SMTP]. If use of the initial response 166 argument would cause the AUTH command to exceed this length, 167 the client MUST NOT use the initial response parameter (and 168 instead proceed as defined in Section 5.1 of [SASL]). 170 If the client is transmitting an initial response of zero 171 length, it MUST instead transmit the response as a single 172 equals sign ("="). This indicates that the response is 173 present, but contains no data. 175 If the client uses an initial-response argument to the AUTH 176 command with a SASL mechanism in which the client does not 177 begin the authentication exchange, the server MUST reject the 178 AUTH command with a 501 reply. Servers using the enhanced 179 status codes extension [ESMTP-CODES] SHOULD return an enhanced 180 status code of 5.7.0 in this case. 182 If the server cannot [BASE64] decode any client response, it 183 MUST reject the AUTH command with a 501 reply (and an enhanced 184 status code of 5.5.2). If the client cannot BASE64 decode any 185 of the server's challenges, it MUST cancel the authentication 186 using the "*" response. In particular, servers and clients 187 MUST reject (and not ignore) any character not explicitly 188 allowed by the BASE64 alphabet, and MUST reject any sequence 189 of BASE64 characters that contains the pad character ('=') 190 anywhere other than the end of the string (e.g. "=AAA" and 191 "AAA=BBB" are not allowed). 193 Note that these [BASE64] strings can be much longer than 194 normal SMTP commands. Clients and servers MUST be able to 195 handle the maximum encoded size of challenges and responses 196 generated by their supported authentication mechanisms. This 197 requirement is independent of any line length limitations the 198 client or server may have in other parts of its protocol 199 implementation. (At the time of writing of this document, 200 12288 is considered to be sufficiently big line length limit 201 for handling of deployed authentication mechanisms.) If, 202 during an authentication exchange, the server receives a line 203 that is longer than the server's authentication buffer, the 204 server fails the AUTH command with the 500 reply. Servers 205 using the enhanced status codes extension [ESMTP-CODES] SHOULD 206 return an enhanced status code of 5.5.6 in this case. 208 The authorization identity generated by this [SASL] exchange 209 is a "simple username" (in the sense defined in [SASLprep]), 210 and both client and server SHOULD (*) use the [SASLprep] 211 profile of the [StringPrep] algorithm to prepare these names 212 for transmission or comparison. If preparation of the 213 authorization identity fails or results in an empty string 214 (unless it was transmitted as the empty string), the server 215 MUST fail the authentication. 217 (*) - Future revision of this specification may change this 218 requirement to MUST. Currently the SHOULD is used in order to 219 avoid breaking the majority of existing implementations. 221 If the server is unable to authenticate the client, it SHOULD 222 reject the AUTH command with a 535 reply unless a more 223 specific error code is appropriate. Should the client 224 successfully complete the exchange, the SMTP server issues a 225 235 reply. (Note that SMTP protocol doesn't support SASL 226 feature for returning additional data with the successful 227 outcome.) These status codes, along with others defined by 228 this extension, are discussed in Section 6 of this document. 230 If a security layer is negotiated during the SASL exchange, it 231 takes effect for the client on the octet immediately following 232 the CRLF that concludes the last response generated by the 233 client. For the server, it takes effect immediately following 234 the CRLF of its success reply. 236 When a security layer takes effect, the SMTP protocol is reset 237 to the initial state (the state in SMTP after a server issues 238 a 220 service ready greeting). The server MUST discard any 239 knowledge obtained from the client, such as the EHLO argument, 240 which was not obtained from the SASL negotiation itself. 241 Likewise, the client MUST discard any knowledge obtained from 242 the server, such as the list of SMTP service extensions, which 243 was not obtained from the SASL negotiation itself (Note that a 244 client MAY compare the advertised SASL mechanisms before and 245 after authentication in order to detect an active down- 246 negotiation attack). 248 The client SHOULD send an EHLO command as the first command 249 after a successful SASL negotiation which results in the 250 enabling of a security layer. 252 When both [TLS] and SASL security layers are in effect, when 253 sending data the TLS encoding MUST be applied after the SASL 254 encoding, regardless of the order in which the layers were 255 negotiated. 257 The service name specified by this protocol's profile of SASL 258 is "smtp". This service name is also to be used for the 259 [SUBMIT] protocol. 261 If an AUTH command fails, the client MAY proceed without 262 authentication, Alternatively, the client MAY try another 263 authentication mechanism or present different credentials by 264 issuing another AUTH command. 266 Note: a server implementation MUST implement a configuration 267 in which it does NOT permit any plaintext password mechanisms, 268 unless either the STARTTLS [SMTP-TLS] command has been 269 negotiated or some other mechanism that protects the session 270 from password snooping has been provided. Server sites SHOULD 271 NOT use any configuration which permits a plaintext password 272 mechanism without such a protection mechanism against password 273 snooping. 275 To ensure interoperability, client and server implementations 276 of this extension MUST implement the [PLAIN] SASL mechanism 277 running over TLS [TLS] [SMTP-TLS]. See also section 15 for 278 additional requirements on implementations of [PLAIN] over 279 [TLS]. 281 Note that many existing client and server implementations 282 implement CRAM-MD5 [CRAM-MD5] SASL mechanism. In order to 283 ensure interoperability with deployed software new 284 implementations MAY implement it, however implementations 285 should be aware that this SASL mechanism doesn't provide any 286 server authentication. Note that at the time of writing of 287 this document the SASL Working Group is working on several 288 replacement SASL mechanisms that provide server authentication 289 and other features. 291 When the AUTH command is used together with the [PIPELINING] 292 extension, it MUST be the last command in a pipelined group of 293 commands. The only exception to this rule is when the AUTH 294 command contains an initial response for a SASL mechanism that 295 allows client to send data first and is known to complete in 296 one round-trip. Two examples of such SASL mechanisms are PLAIN 297 [PLAIN] and EXTERNAL [SASL]. 299 4.1. Examples 301 Here is an example of a client attempting AUTH using the [PLAIN] 302 SASL mechanism under a TLS layer, and making use of the initial 303 client response: 305 S: 220-smtp.example.com ESMTP Server 306 C: EHLO client.example.com 307 S: 250-smtp.example.com Hello client.example.com 308 S: 250-AUTH GSSAPI DIGEST-MD5 309 S: 250-ENHANCEDSTATUSCODES 310 S: 250 STARTTLS 311 C: STARTTLS 312 S: 220 Ready to start TLS 313 ... TLS negotiation proceeds, further commands 314 protected by TLS layer ... 315 C: EHLO client.example.com 316 S: 250-smtp.example.com Hello client.example.com 317 S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN 318 C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ= 319 S: 235 2.7.0 Authentication successful 321 Here is another client that is attempting AUTH PLAIN under a TLS 322 layer, this time without the initial response. Parts of the 323 negotiation before the TLS layer was established have been omitted: 325 ... TLS negotiation proceeds, further commands 326 protected by TLS layer ... 327 C: EHLO client.example.com 328 S: 250-smtp.example.com Hello client.example.com 329 S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN 330 C: AUTH PLAIN 331 (note: there is a single space following the 334 332 on the following line) 333 S: 334 334 C: dGVzdAB0ZXN0ADEyMzQ= 335 S: 235 2.7.0 Authentication successful 337 Here is an example using CRAM-MD5 [CRAM-MD5], a mechanism in which 338 the client does not begin the authentication exchange, and includes 339 a server challenge: 341 S: 220-smtp.example.com ESMTP Server 342 C: EHLO client.example.com 343 S: 250-smtp.example.com Hello client.example.com 344 S: 250-AUTH DIGEST-MD5 CRAM-MD5 345 S: 250-ENHANCEDSTATUSCODES 346 S: 250 STARTTLS 347 C: AUTH CRAM-MD5 348 S: 334 PDQxOTI5NDIzNDEuMTI4Mjg0NzJAc291cmNlZm91ci5hbmRyZXcuY211LmVk 349 dT4= 350 C: cmpzMyBlYzNhNTlmZWQzOTVhYmExZWM2MzY3YzRmNGI0MWFjMA== 351 S: 235 2.7.0 Authentication successful 353 Here is an example of a client attempting AUTH EXTERNAL under TLS, 354 using the derived authorization ID (and thus a zero-length initial 355 client response). 357 S: 220-smtp.example.com ESMTP Server 358 C: EHLO client.example.com 359 S: 250-smtp.example.com Hello client.example.com 360 S: 250-AUTH GSSAPI DIGEST-MD5 361 S: 250-ENHANCEDSTATUSCODES 362 S: 250 STARTTLS 363 C: STARTTLS 364 S: 220 Ready to start TLS 365 ... TLS negotiation proceeds, further commands 366 protected by TLS layer ... 367 C: EHLO client.example.com 368 S: 250-smtp.example.com Hello client.example.com 369 S: 250 AUTH EXTERNAL GSSAPI DIGEST-MD5 PLAIN 370 C: AUTH EXTERNAL = 371 S: 235 2.7.0 Authentication successful 373 5. The AUTH Parameter to the MAIL FROM command 375 AUTH=mailbox 377 Arguments: 378 A (see section 4.1.2 of [SMTP]) that is associated 379 with the identity which submitted the message to the delivery 380 system, or the two character sequence "<>" indicating such an 381 identity is unknown or insufficiently authenticated. To comply 382 with restrictions imposed on ESMTP parameters, the is 383 encoded inside an xtext. The syntax of an xtext is described in 384 Section 4 of [ESMTP-DSN]. 386 Note: 387 For the purposes of this discussion, "authenticated identity" 388 refers to the identity (if any) derived from the authorization 389 identity of previous AUTH command, while the terms "authorized 390 identity" and "supplied " refer to the sender identity 391 that is being associated with a particular message. Note that 392 one authenticated identity may be able to identify messages as 393 being sent by any number of authorized identities within a 394 single session. For example, this may be the case when an SMTP 395 server (one authenticated identity) is processing its queue 396 (many messages with distinct authorized identities). 398 Discussion: 399 The optional AUTH parameter to the MAIL FROM command allows 400 cooperating agents in a trusted environment to communicate the 401 authorization identity associated with individual messages. 403 If the server trusts the authenticated identity of the client to 404 assert that the message was originally submitted by the supplied 405 , then the server SHOULD supply the same in 406 an AUTH parameter when relaying the message to any other server 407 which supports the AUTH extension. 409 For this reason, servers that advertise support for this 410 extension MUST support the AUTH parameter to the MAIL FROM 411 command even when the client has not authenticated itself to the 412 server. 414 A MAIL FROM parameter of AUTH=<> indicates that the original 415 submitter of the message is not known. The server MUST NOT 416 treat the message as having been originally submitted by 417 authenticated identity which resulted from the AUTH command. 419 If the AUTH parameter to the MAIL FROM command is not supplied, 420 the client has authenticated, and the server believes the 421 message is an original submission, the server MAY generate a 422 from the user's authenticated identity for use in an 423 AUTH parameter when relaying the message to any server which 424 supports the AUTH extension. The generated is 425 implementation specific, but it MUST conform to the syntax of 426 [SMTP]. If the implementation cannot generate a valid 427 , it MUST transmit AUTH=<> when relaying this message. 429 If the server does not sufficiently trust the authenticated 430 identity of the client, or if the client is not authenticated, 431 then the server MUST behave as if the AUTH=<> parameter was 432 supplied. The server MAY, however, write the value of any 433 supplied AUTH parameter to a log file. 435 If an AUTH=<> parameter was supplied, either explicitly or due 436 to the requirement in the previous paragraph, then the server 437 MUST supply the AUTH=<> parameter when relaying the message to 438 any server which it has authenticated to using the AUTH 439 extension. 441 A server MAY treat expansion of a mailing list as a new 442 submission, setting the AUTH parameter to the mailing list 443 address or mailing list administration address when relaying the 444 message to list subscribers. 446 Note that an implementation which is hard-coded to treat all 447 clients as being insufficiently trusted is compliant with this 448 specification. In that case, the implementation does nothing 449 more than parse and discard syntactically valid AUTH parameters 450 to the MAIL FROM command, and supply AUTH=<> parameters to any 451 servers which it authenticates to. 453 5.1. Examples 455 An example where the original identity of the sender is trusted and 456 known: 458 C: MAIL FROM: AUTH=e+3Dmc2@example.com 459 S: 250 OK 461 One example where the identity of the sender is not trusted or is 462 otherwise being suppressed by the client: 464 C: MAIL FROM: AUTH=<> 465 S: 250 OK 467 6. Status Codes 469 The following error codes may be used to indicate various success or 470 failure conditions. Servers that return enhanced status codes 471 [ESMTP-CODES] SHOULD use the enhanced codes suggested here. 473 235 2.7.0 Authentication Succeeded 475 This response to the AUTH command indicates that the authentication 476 was successful. 478 432 4.7.12 A password transition is needed 480 This response to the AUTH command indicates that the user needs to 481 transition to the selected authentication mechanism. This is 482 typically done by authenticating once using the [PLAIN] 483 authentication mechanism. The selected mechanism SHOULD then work 484 for authentications in subsequent sessions. 486 454 4.7.0 Temporary authentication failure 488 This response to the AUTH command indicates that the authentication 489 failed due to a temporary server failure. The client SHOULD NOT 490 prompt the user for another password in this case, and instead 491 notify the user of server failure. 493 534 5.7.9 Authentication mechanism is too weak 495 This response to the AUTH command indicates that the selected 496 authentication mechanism is weaker than server policy permits for 497 that user. The client SHOULD retry with a new authentication 498 mechanism. 500 535 5.7.8 Authentication credentials invalid 502 This response to the AUTH command indicates that the authentication 503 failed due to invalid or insufficient authentication credentials. 504 In this case, the client SHOULD ask the user to supply new 505 credentials (such as by presenting a password dialog box). 507 500 5.5.6 Authentication Exchange line is too long 509 This response to the AUTH command indicates that the authentication 510 failed due to the client sending a [BASE64] response which is longer 511 than the maximum buffer size available for the currently selected 512 SASL mechanism. 514 530 5.7.0 Authentication required 516 This response SHOULD be returned by any command other than AUTH, 517 EHLO, HELO, NOOP, RSET, or QUIT when server policy requires 518 authentication in order to perform the requested action and 519 authentication is not currently in force. 521 538 5.7.11 Encryption required for requested authentication 522 mechanism 524 This response to the AUTH command indicates that the selected 525 authentication mechanism may only be used when the underlying SMTP 526 connection is encrypted. Note that this response code is documented 527 here for historical purposes only. Modern implementations SHOULD 528 NOT advertise mechanisms that are not permitted due to lack of 529 encryption, unless an encryption layer of sufficient strength is 530 currently being employed. 532 This document adds several new enhanced status code to the list 533 defined in [ENHANCED]: 535 The following 3 Enhanced Status Codes were defined above: 537 5.7.8 Authentication credentials invalid 538 5.7.9 Authentication mechanism is too weak 539 5.7.11 Encryption required for requested authentication mechanism 541 X.5.6 Authentication Exchange line is too long 543 This enhanced status code SHOULD be returned when the server fails 544 the AUTH command due to the client sending a [BASE64] response which 545 is longer than the maximum buffer size available for the currently 546 selected SASL mechanism. This is useful for both permanent and 547 persistent transient errors. 549 7. Additional requirements on servers 551 As described in Section 4.4 of [SMTP], an SMTP server that receives 552 a message for delivery or further processing MUST insert the 553 "Received:" header field at the beginning of the message content. 554 This document places additional requirements on the content of a 555 generated "Received:" header field. Upon successful authentication a 556 server SHOULD use the "ESMTPA" or the "ESMTPSA" [SMTP-TT] (when 557 appropriate) keyword in the "with" clause of the Received header 558 field. 560 8. Formal Syntax 562 The following syntax specification uses the Augmented Backus-Naur 563 Form notation as specified in [ABNF]. Non-terminals referenced but 564 not defined below are as defined by [ABNF] or [SASL]. The non- 565 terminal is defined in [SMTP]. 567 Except as noted otherwise, all alphabetic characters are case- 568 insensitive. The use of upper or lower case characters to define 569 token strings is for editorial clarity only. Implementations MUST 570 accept these strings in a case-insensitive fashion. 572 hexchar = "+" HEXDIG HEXDIG 573 xchar = %x21-2A / %x2C-3C / %x3E-7E 574 ;; US-ASCII except for "+", "=", SP and CTL 576 xtext = *(xchar / hexchar) 577 ;; non-US-ASCII is only allowed as hexchar 579 auth-command = "AUTH" SP sasl-mech [SP initial-response] 580 *(CRLF [base64]) [CRLF cancel-response] 581 CRLF 582 ;; is defined in [SASL] 584 auth-param = "AUTH=" xtext 585 ;; Parameter to the MAIL FROM command. 586 ;; This non-terminal complies with 587 ;; syntax defined by esmtp-param [SMTP]. 588 ;; 589 ;; The decoded form of the xtext MUST be 590 ;; either a or the two 591 ;; characters "<>" 593 base64 = base64-terminal / 594 ( 1*(4base64-char) [base64-terminal] ) 596 base64-char = ALPHA / DIGIT / "+" / "/" 597 ;; Case-sensitive 599 base64-terminal = (2base64-char "==") / (3base64-char "=") 601 continue-req = "334" SP [base64] CRLF 602 ;; Intermediate response to the AUTH 603 ;; command. 604 ;; This non-terminal complies with 605 ;; syntax defined by Reply-line [SMTP]. 607 initial-response= base64 / "=" 609 cancel-response = "*" 611 9. Security Considerations 613 Security issues are discussed throughout this memo. 615 If a client uses this extension to get an encrypted tunnel through 616 an insecure network to a cooperating server, it needs to be 617 configured to never send mail to that server when the connection is 618 not mutually authenticated and encrypted. Otherwise, an attacker 619 could steal the client's mail by hijacking the [SMTP] connection and 620 either pretending the server does not support the Authentication 621 extension or causing all AUTH commands to fail. 623 Before the [SASL] negotiation has begun, any protocol interactions 624 are performed in the clear and may be modified by an active 625 attacker. For this reason, clients and servers MUST discard any 626 knowledge obtained prior to the start of the SASL negotiation upon 627 the establishment of a security layer. 629 This mechanism does not protect the TCP port, so an active attacker 630 may redirect a relay connection attempt (i.e. a connection between 631 two MTAs) to the submission port [SUBMIT]. The AUTH=<> parameter 632 prevents such an attack from causing a relayed message, in the 633 absence of other envelope authentication, from picking up the 634 authentication of the relay client. 636 A message submission client may require the user to authenticate 637 whenever a suitable [SASL] mechanism is advertised. Therefore, it 638 may not be desirable for a submission server [SUBMIT] to advertise a 639 SASL mechanism when use of that mechanism grants the clients no 640 benefits over anonymous submission. 642 Servers MAY implement a policy whereby the connection is dropped 643 after a number of failed authentication attempts. If they do so, 644 they SHOULD NOT drop the connection until at least 3 attempts to 645 authenticate have failed. 647 If an implementation supports SASL mechanisms that are vulnerable to 648 passive eavesdropping attacks (such as [PLAIN]), then the 649 implementation MUST support at least one configuration where these 650 SASL mechanisms are not advertised or used without the presence of 651 an external security layer such as [TLS]. 653 This extension is not intended to replace or be used instead of end- 654 to-end message signature and encryption systems such as [S/MIME] or 655 [PGP]. This extension addresses a different problem than end-to-end 656 systems; it has the following key differences: 658 1. It is generally useful only within a trusted enclave. 660 2. It protects the entire envelope of a message, not just the 661 message's body. 663 3. It authenticates the message submission, not authorship of the 664 message content. 666 4. When mutual authentication is used along with a security 667 layer, it can give the sender some assurance that the message 668 was successfully delivered to the next hop. 670 Additional security considerations are mentioned in the [SASL] 671 specification. Additional security considerations specific to a 672 particular SASL mechanism are described in the relevant 673 specification. Additional security considerations for [PLAIN] over 674 [TLS] are mentioned in Section 15 of this document. 676 10. IANA Considerations 678 This document requests that the IANA update the entry for the "smtp" 679 SASL protocol name to point at this document. 681 This document requests that the IANA updates registration of the 682 Authentication SMTP service extension as defined in Section 3 of 683 this document. This registry is currently located at 684 . 686 11. Normative References 688 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 689 Specifications: ABNF", RFC 4234, October 2005. 691 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 692 Encodings", RFC 4648, October 2006. 694 [ESMTP-CODES] 695 Freed, N., "SMTP Service Extension for Returning Enhanced 696 Error Codes", RFC 2034, October 1996. 698 [ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 699 3463, January 2003. 701 [ESMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 702 Extension Delivery Status Notifications (DSNs)", RFC 3461, 703 January 2003. 705 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 706 Requirement Levels", BCP 14, RFC 2119, March 1997. 708 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 709 Security Layer (SASL)", RFC 4422, June 2006. 711 [SASLprep] Zeilega, K., "SASLprep: Stringprep profile for user names 712 and passwords", RFC 4013, February 2005. 714 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 715 April 2001. 717 [SMTP-TLS] Hoffman, P. "SMTP Service Extension for Secure SMTP over 718 Transport Layer Security", RFC 3207, February 2002. 720 [StringPrep] 721 Hoffman, P., Blanchet, M., "Preparation of Internationalized 722 Strings ("stringprep")", RFC 3454, December 2002. 724 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", 725 RFC 4409, April 2006. 727 [SMTP-TT] Newman, C., "ESMTP and LMTP Transmission Types 728 Registration", RFC 3848, July 2004. 730 [PLAIN] Zeilenga, K. (Ed.), "The PLAIN Simple Authentication and 731 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 733 [X509] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 734 Public Key Infrastructure Certificate and Certificate 735 Revocation List (CRL) Profile", RFC 3280, April 2002. 737 12. Informative References 739 [PGP] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", 740 RFC 2015, October 1996. 742 [S/MIME] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 743 2633, June 1999. 745 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 746 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 748 [PIPELINING] 749 Freed, N., "SMTP Service Extension for Command Pipelining", 750 RFC 2920, September 2000. 752 [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, IMAP/POP AUTHorize 753 Extension for Simple Challenge/Response", RFC 2195, 754 September 1997. 756 13. Editors' Addresses 758 Robert Siemborski 759 Google, Inc. 760 1600 Ampitheatre Parkway 761 Mountain View, CA 94043, USA 762 +1 650 623 6925 763 robsiemb@google.com 765 Alexey Melnikov 766 Isode Limited 767 5 Castle Business Village, 36 Station Road, 768 Hampton, Middlesex, TW12 2BX, UK 769 Alexey.Melnikov@isode.com 771 14. Acknowledgments: 773 Editors would like to acknowledge the contributions of John Myers 774 and other contributors to RFC 2554, on which this document draws 775 from heavily. 777 Editors would also like to thank Ken Murchison, Mark Crispin, Chris 778 Newman, David Wilson, Dave Cridland, Frank Ellermann, Ned Freed, 779 John Klensin, Tony Finch, Abhijit Menon-Sen, Philip Guenther, Sam 780 Hartman, Russ Housley, Cullen Jennings and Lisa Dusseault for the 781 time they devoted to reviewing of this document and/or for the 782 comments received. 784 15. Additional requirements when using SASL PLAIN over TLS 786 This section is normative for SMTP implementations that support SASL 787 [PLAIN] over [TLS]. 789 If an SMTP client is willing to use SASL PLAIN over TLS to 790 authenticate to the SMTP server, the client verifies the server 791 certificate according to the rules of [X509]. If the server has not 792 provided any certificate, or if the certificate verification fails, 793 the client MUST NOT attempt to authenticate using the SASL PLAIN 794 mechanism. 796 After a successful [TLS] negotiation, the client MUST check its 797 understanding of the server hostname against the server's identity 798 as presented in the server Certificate message, in order to prevent 799 man-in-the-middle attacks. If the match fails, the client MUST NOT 800 attempt to authenticate using the SASL PLAIN mechanism. Matching is 801 performed according to the following rules: 803 The client MUST use the server hostname it used to open the 804 connection as the value to compare against the server name as 805 expressed in the server certificate. The client MUST NOT use 806 any form of the server hostname derived from an insecure remote 807 source (e.g., insecure DNS lookup). CNAME canonicalization is 808 not done. 810 If a subjectAltName extension of type dNSName is present in the 811 certificate, it SHOULD be used as the source of the server's 812 identity. 814 Matching is case-insensitive. 816 A "*" wildcard character MAY be used as the left-most name 817 component in the certificate. For example, *.example.com would 818 match a.example.com, foo.example.com, etc. but would not match 819 example.com. 821 If the certificate contains multiple names (e.g., more than one 822 dNSName field), then a match with any one of the fields is 823 considered acceptable. 825 16. Changes Since RFC 2554 827 1. Clarify that servers MUST support the use of the AUTH=mailbox 828 parameter to MAIL FROM, even when the client is not 829 authenticated. 831 2. Clarify the initial-client-send requirements, and give 832 additional examples. 834 3. Update references to newer versions of various specifications. 836 4. Require SASL PLAIN (over TLS) as mandatory-to-implement. 838 5. Clarify that the mechanism list can change. 840 6. Deprecate the use of the 538 response code. 842 7. Add the use of the SASLprep profile for preparing 843 authorization identities. 845 8. Substantial cleanup of response codes and indicate suggested 846 enhanced response codes. Also indicate what response codes 847 should result in a client prompting the user for new 848 credentials. 850 9. Updated ABNF section to use RFC 4234. 852 10. Clarified interaction with SMTP PIPELINING extension. 854 11. Added a reference to RFC 3848. 856 12. Added a new Enhanced Status Code for "authentication line too 857 long" case. 859 13. General other editorial clarifications. 861 17. Intellectual Property 863 The IETF takes no position regarding the validity or scope of any 864 Intellectual Property Rights or other rights that might be claimed 865 to pertain to the implementation or use of the technology described 866 in this document or the extent to which any license under such 867 rights might or might not be available; nor does it represent that 868 it has made any independent effort to identify any such rights. 869 Information on the procedures with respect to rights in RFC 870 documents can be found in BCP 78 and BCP 79. 872 Copies of IPR disclosures made to the IETF Secretariat and any 873 assurances of licenses to be made available, or the result of an 874 attempt made to obtain a general license or permission for the use 875 of such proprietary rights by implementers or users of this 876 specification can be obtained from the IETF on-line IPR repository 877 at http://www.ietf.org/ipr. 879 The IETF invites any interested party to bring to its attention any 880 copyrights, patents or patent applications, or other proprietary 881 rights that may cover technology that may be required to implement 882 this standard. Please address the information to the IETF at ietf- 883 ipr@ietf.org. 885 18. Full Copyright Statement 887 Copyright (C) The IETF Trust (2007). 889 This document is subject to the rights, licenses and restrictions 890 contained in BCP 78, and except as set forth therein, the authors 891 retain all their rights. 893 This document and the information contained herein are provided on 894 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 895 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 896 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 897 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 898 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 899 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 900 FOR A PARTICULAR PURPOSE. 902 Acknowledgement 904 Funding for the RFC Editor function is currently provided by the 905 Internet Society. 907 Table of Contents 909 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 910 2. How to Read This Document . . . . . . . . . . . . . . . . . . . . 3 911 3. The Authentication Service Extension . . . . . . . . . . . . . . 3 912 4. The AUTH Command . . . . . . . . . . . . . . . . . . . . . . . . 4 913 4.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 914 5. The AUTH Parameter to the MAIL FROM command . . . . . . . . . . . 9 915 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 916 6. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 11 917 7. Additional requirements on servers . . . . . . . . . . . . . . . 13 918 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13 919 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 14 920 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 921 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 16 922 12. Informative References . . . . . . . . . . . . . . . . . . . . . 17 923 13. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 924 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 18 925 15. Additional requirements when using SASL PLAIN over TLS . . . . . 18 926 16. Changes Since RFC 2554 . . . . . . . . . . . . . . . . . . . . . 19 927 17. Intellectual Property . . . . . . . . . . . . . . . . . . . . . 20 928 18. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 20