idnits 2.17.1 draft-myers-smtp-auth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 68: '...pletes, a server MUST reject any furth...' RFC 2119 keyword, line 157: '...dr-spec, then the server SHOULD supply...' RFC 2119 keyword, line 163: '... then the server MUST behave as if no ...' RFC 2119 keyword, line 164: '...ied. The server MAY, however, place t...' RFC 2119 keyword, line 168: '... A server MAY treat expansion o...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 1995) is 10605 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) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Myers 3 Internet Draft: SMTP Authentication Carnegie Mellon 4 Document: draft-myers-smtp-auth-00.txt April 1995 6 SMTP Service Extension 7 for Authentication 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 ``working draft'' or ``work in progress``. 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the RFC 27 editor as a Proposed Standard for the Internet Community. Discussion 28 and suggestions for improvement are requested. This document will 29 expire before 15 Oct 1995. Distribution of this draft is unlimited. 31 1. Introduction 33 This document defines an extension to the SMTP service whereby an 34 SMTP client may indicate an authentication mechanism to the server, 35 perform an authentication protocol exchange, and optionally negotiate 36 a protection mechanism for subsequent protocol interactions. The 37 authentication and protection mechanisms used by the the SMTP AUTH 38 extension are those used by the IMAP4 protocol. A mechanism is also 39 provided for a client to transfer envelope authentication of 40 individual messages. 42 2. The Authentication service extension 44 (1) the name of the SMTP service extension is "Authentication" 46 (2) the EHLO keyword value associated with this extension is "AUTH" 48 (3) no parameter is used with the AUTH EHLO keyword 50 (4) a new SMTP verb "AUTH" is defined 52 (5) an optional parameter using the keyword "AUTH" is added to the 53 MAIL FROM command. 55 3. The AUTH command 57 AUTH mechanism 59 Arguments: 60 a string identifying an IMAP4 authentication mechanism, such as 61 defined by [IMAP4-AUTH]. Any use of the string "imap" used in 62 a server authentication identity in the definition of an 63 authentication mechanism is replaced with the string "smtp". 65 Restrictions: 66 after an AUTH command has successfully completed, no more AUTH 67 commands may be issued in the same session. After a successful 68 AUTH command completes, a server MUST reject any further AUTH 69 commands with a 503 reply. 71 Discussion: 72 The AUTH command indicates an authentication mechanism to the 73 server. If the server supports the requested authentication 74 mechanism, it performs an authentication protocol exchange to 75 authenticate and identify the user. Optionally, it also 76 negotiates a protection mechanism for subsequent protocol 77 interactions. If the requested authentication mechanism is not 78 supported, the server should reject the AUTH command with a 504 79 reply. 81 The authentication protocol exchange consists of a series of 82 server challenges and client answers that are specific to the 83 authentication mechanism. A server challenge, otherwise known 84 as a ready response, is a 334 reply with the text part 85 containing a BASE64 encoded string. The client answer consists 86 of a line containing a BASE64 encoded string. If the client 87 wishes to cancel an authentication exchange, it should issue a 88 line with a single "*". If the server receives such an answer, 89 it must reject the AUTH command by sending a 501 reply. 91 If the server cannot BASE64 decode the argument, it should 92 reject the AUTH command with a 501 reply. If the server 93 rejects the authentication data, it should reject the AUTH 94 command with a 535 reply. Should the client successfully 95 complete the authentication exchange, the SMTP server issues a 96 235 reply. 98 A protection mechanism provides integrity and privacy 99 protection to the protocol session. If a protection mechanism 100 is negotiated, it is applied to all subsequent data sent over 101 the connection. The protection mechanism takes effect 102 immediately following the CRLF that concludes the 103 authentication exchange for the client, and the CRLF of the 104 success reply for the server. Once the protection mechanism is 105 in effect, the stream of command and response octets is 106 processed into buffers of ciphertext. Each buffer is 107 transferred over the connection as a stream of octets prepended 108 with a four octet field in network byte order that represents 109 the length of the following data. The maximum ciphertext 110 buffer length is defined by the protection mechanism. 112 The server is not required to support any particular 113 authentication mechanism, nor are authentication mechanisms 114 required to support any protection mechanisms. If an AUTH 115 command fails, the client may try another authentication 116 mechanism by issuing another AUTH command. In other words, the 117 client may request authentication types in decreasing order of 118 preference. 120 The BASE64 string may in general be arbitrarily long. Clients 121 and servers must be able to support challenges and responses 122 that are as long as are generated by the authentication 123 mechanisms they support, independent of any line length 124 limitations the client or server may have in other parts of its 125 protocol implementation. 127 Examples: 128 S: 220 smtp.andrew.cmu.edu ESMTP server ready 129 C: EHLO jgm.pc.cc.cmu.edu 130 S: 250-smtp.andrew.cmu.edu 131 S: 250 AUTH 132 C: AUTH FOOBAR 133 S: 504 Unrecognized authentication type 134 C: AUTH SKEY 135 S: 334 136 C: c21pdGg= 137 S: 334 OTUgUWE1ODMwOA== 138 C: BsAY3g4gBNo= 139 S: 235 S/Key authentication successful 141 3. The AUTH parameter to the MAIL FROM command 143 AUTH=addr-spec 145 Arguments: 146 an addr-spec containing the identity which submitted the 147 message to the delivery system. [[length limit? the 64@64 148 limit of 821 seems a bit small]] 150 Discussion: 151 The optional AUTH parameter to the MAIL FROM command allows 152 cooperating agents in a trusted environment to communicate 153 the authentication of individual messages. 155 If the server trusts the authenticated identity of the 156 client to assert that the message was originally submitted 157 by the supplied addr-spec, then the server SHOULD supply 158 the same addr-spec in an AUTH parameter when relaying the 159 message to any server which supports the AUTH extension. 161 If the server does not sufficiently trust the authenticated 162 identity of the client, or if the client is not 163 authenticated, then the server MUST behave as if no AUTH 164 parameter was supplied. The server MAY, however, place the 165 value of the AUTH parameter in a comment in the inserted 166 Received: header and/or write it to a log file. 168 A server MAY treat expansion of a mailing list as a new 169 submission, setting the AUTH parameter to the mailing list 170 address or mailing list administration address when 171 relaying the message to list subscribers. 173 [[encoding spaces or equal signs in the addr-spec?]] 175 5. Formal Syntax 177 The following syntax specification uses the augmented Backus-Naur 178 Form (BNF) notation as specified in RFC 822. 180 Except as noted otherwise, all alphabetic characters are case- 181 insensitive. The use of upper or lower case characters to define 182 token strings is for editorial clarity only. Implementations MUST 183 accept these strings in a case-insensitive fashion. 185 ATOM_CHAR ::= 187 atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / "%" / "*" / 188 <"> / "\" 190 auth_command ::= "AUTH" SPACE auth_type *(CRLF base64) CRLF 192 auth_param ::= "AUTH=" addr-spec 193 ;; addr-spec may not contain SPACE, "=" 194 ;; or CTL characters. 196 auth_type ::= 1*ATOM_CHAR 198 base64 ::= *(4base64_CHAR) [base64_terminal] 200 base64_char ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / 201 "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / 202 "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / 203 "Y" / "Z" / 204 "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / 205 "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / 206 "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / 207 "y" / "z" / 208 "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / 209 "8" / "9" / "+" / "/" 210 ;; Case-sensitive 212 base64_terminal ::= (2base64_char "==") / (3base64_char "=") 214 CHAR ::= 217 continue_req ::= "334" SPACE base64 CRLF 219 CR ::= 221 CRLF ::= CR LF 222 CTL ::= 225 LF ::= 227 SPACE ::= 229 4. References 231 [IMAP4-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, 232 Carnegie Mellon, December 1994. 234 5. Security Considerations 236 Security issues are discussed throughout this memo. 238 If a client uses this extension to get an encrypted tunnel through an 239 insecure network to a cooperating server, it needs to be configured 240 to never send mail to that server when the connection is not mutually 241 authenticated and encrypted. Otherwise, an attacker could steal the 242 client's mail by hijacking the SMTP connection and either pretending 243 the server does not support the Authentication extension or causing 244 all AUTH commands to fail. 246 This extension does not provide a defined mechanism for 247 authentication using a plaintext password. This omission is 248 intentional. 250 This extension is not intended to replace or be used instead of end- 251 to-end message signature and encryption systems such as PEM or PGP. 252 This extension addresses a different problem than end-to-end systems; 253 it has the following key differences: 255 (1) it is generally useful only within a trusted enclave 257 (2) it protects the entire envelope of a message, not just the 258 message's body. 260 (3) it authenticates the message submission, not authorship of the 261 message content 263 (4) it can give the sender some assurance the message was delivered 264 to the next hop 266 6. Author's Address: 268 John G. Myers 269 Carnegie-Mellon University 270 5000 Forbes Ave 271 Pittsburgh, PA 15213 273 EMail: jgm+@cmu.edu