idnits 2.17.1 draft-hoffman-smtp-ssl-09.txt: ** The Abstract section seems to be numbered 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-19) 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 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 290 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There are 54 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == 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 97: '...nced SMTP server MUST NOT require use ...' RFC 2119 keyword, line 112: '...case, the server SHOULD return the rep...' RFC 2119 keyword, line 118: '...s code to be returned SHOULD be 5.7.0....' RFC 2119 keyword, line 120: '... a STARTTLS command, the client SHOULD...' RFC 2119 keyword, line 128: '...mpleted, both parties MUST immediately...' (12 more instances...) 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 (October 25, 1998) is 9308 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) -- Missing reference section? 'RFC-821' on line 252 looks like a reference -- Missing reference section? 'TLS' on line 264 looks like a reference -- Missing reference section? 'RFC-2034' on line 256 looks like a reference -- Missing reference section? 'SASL' on line 259 looks like a reference -- Missing reference section? 'SMTP-AUTH' on line 261 looks like a reference -- Missing reference section? 'MIME-SEC' on line 244 looks like a reference -- Missing reference section? 'RFC-1869' on line 254 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Paul Hoffman 2 draft-hoffman-smtp-ssl-09.txt Internet Mail Consortium 3 October 25, 1998 4 Expires in six months 6 SMTP Service Extension for Secure SMTP over TLS 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are working documents 11 of the Internet Engineering Task Force (IETF), its areas, and its working 12 groups. Note that other groups may also distribute working documents as 13 Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months and 16 may be updated, replaced, or obsoleted by other documents at any time. It 17 is inappropriate to use Internet-Drafts as reference material or to cite 18 them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au 23 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West 24 Coast). 26 1. Abstract 28 This document describes an extension to the SMTP service that allows an 29 SMTP server and client to use transport-layer security to provide private, 30 authenticated communication over the Internet. This gives SMTP agents the 31 ability to protect some or all of their communications from eavesdroppers 32 and attackers. 34 2. Introduction 36 SMTP [RFC-821] servers and clients normally communicate in the clear over 37 the Internet. In many cases, this communication goes through one or more 38 router that is not controlled or trusted by either entity. Such an 39 untrusted router might allow a third party to monitor or alter the 40 communications between the server and client. 42 Further, there is often a desire for two SMTP agents to be able to 43 authenticate each others' identities. For example, a secure SMTP server 44 might only allow communications from other SMTP agents it knows, or it 45 might act differently for messages received from an agent it knows than 46 from one it doesn't know. 48 TLS [TLS], more commonly known as SSL, is a popular mechanism for enhancing 49 TCP communications with privacy and authentication. TLS is in wide use with 50 the HTTP protocol, and is also being used for adding security to many other 51 common protocols that run over TCP. 53 2.1 Discussion of this Draft 55 This draft is being discussed on the "ietf-apps-tls" mailing list. To 56 subscribe, send a message to: 57 ietf-apps-tls-request@imc.org 58 with the single word 59 subscribe 60 in the body of the message. There is a Web site for the mailing list at 61 . 63 3. STARTTLS Extension 65 The STARTTLS extension to SMTP is laid out as follows: 67 (1) the name of the SMTP service defined here is STARTTLS; 69 (2) the EHLO keyword value associated with the extension is STARTTLS; 71 (3) the STARTTLS keyword has no parameters; 73 (4) a new SMTP verb, "STARTTLS", is defined; 75 (5) no additional parameters are added to any SMTP command. 77 4. The STARTTLS Keyword 79 The STARTTLS keyword is used to tell the SMTP client that the SMTP server 80 allows use of TLS. It takes no parameters. 82 5. The STARTTLS Command 84 The format for the STARTTLS command is: 86 STARTTLS 88 with no parameters. 90 After the client gives the STARTTLS command, the server responds with one 91 of the following reply codes: 93 220 Ready to start TLS 94 501 Syntax error (no parameters allowed) 95 454 TLS not available due to temporary reason 97 A publicly-referenced SMTP server MUST NOT require use of the STARTTLS 98 extension in order to deliver mail locally. This rule prevents the STARTTLS 99 extension from damaging the interoperability of the Internet's SMTP 100 infrastructure. A publicly-referenced SMTP server is an SMTP server which 101 runs on port 25 of an Internet host listed in the MX record (or A record if 102 an MX record is not present) for the domain name on the right hand side of 103 an Internet mail address. 105 Any SMTP server may refuse to accept messages for relay based on 106 authentication supplied during the TLS negotiation. An SMTP server that is 107 not publicly referenced may refuse to accept any messages for relay or 108 local delivery based on authentication supplied during the TLS negotiation. 110 A SMTP server that is not publicly referenced may choose to require that 111 the client perform a TLS negotiation before accepting any commands. In this 112 case, the server SHOULD return the reply code: 114 530 Must issue a STARTTLS command first 116 to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the client 117 and server are using the ENHANCEDSTATUSCODES ESMTP extension [RFC-2034], 118 the status code to be returned SHOULD be 5.7.0. 120 After receiving a 220 response to a STARTTLS command, the client SHOULD 121 start the TLS negotiation before giving any other SMTP commands. 123 If the SMTP client is using pipelining as defined in RFC 1854, the STARTTLS 124 command must be the last command in a group. 126 5.1 Processing After the STARTTLS Command 128 After the TLS handshake has been completed, both parties MUST immediately 129 decide whether or not to continue based on the authentication and privacy 130 achieved. The SMTP client and server may decide to move ahead even if the 131 TLS negotiation ended with no authentication and/or no privacy because most 132 SMTP services are performed with no authentication and no privacy, but some 133 SMTP clients or servers may want to continue only if a particular level of 134 authentication and/or privacy was achieved. 136 If the SMTP client decides that the level of authentication or privacy is 137 not high enough for it to continue, it SHOULD issue an SMTP QUIT command 138 immediately after the TLS negotiation is complete. If the SMTP server 139 decides that the level of authentication or privacy is not high enough for 140 it to continue, it SHOULD reply to every SMTP command from the client 141 (other than a QUIT command) with the 554 reply code (with a possible text 142 string such as "Command refused due to lack of security"). 144 The decision of whether or not to believe the authenticity of the other 145 party in a TLS negotiation is a local matter. However, some general rules 146 for the decisions are: 147 - A SMTP client would probably only want to authenticate an SMTP 148 server whose server certificate has a domain name that is the 149 domain name that the client thought it was connecting to. 150 - A publicly-referenced SMTP server would probably want to accept 151 any certificate from an SMTP client, and would possibly want to 152 put distinguishing information about the certificate in the 153 Received header of messages that were relayed or submitted from 154 the client. 156 5.2 Result of the STARTTLS Command 158 Upon completion of the TLS handshake, the SMTP protocol is reset to the 159 initial state (the state in SMTP after a server issues a 220 service ready 160 greeting). The server MUST discard any knowledge obtained from the client, 161 such as the argument to the EHLO command, which was not obtained from the 162 TLS negotiation itself. The client MUST discard any knowledge obtained from 163 the server, such as the list of SMTP service extensions, which was not 164 obtained from the TLS negotiation itself. The client SHOULD send an EHLO 165 command as the first command after a successful TLS negotiation. 167 The list of SMTP service extensions returned in response to an EHLO command 168 received after the TLS handshake MAY be different than the list returned 169 before the TLS handshake. For example, an SMTP server might not want to 170 advertise support for a particular SASL mechanism [SASL] unless a client 171 has sent an appropriate client certificate during a TLS handshake. 173 Both the client and the server MUST know if there is a TLS session active. 174 A client MUST NOT attempt to start a TLS session if a TLS session is 175 already active. A server MUST NOT return the TLS extension in response to 176 an EHLO command received after a TLS handshake has completed. 178 6. Usage Example 180 The following dialog illustrates how a client and server can start a TLS 181 session: 183 S: 184 C: 185 S: 220 mail.imc.org SMTP service ready 186 C: EHLO mail.ietf.org 187 S: 250-mail.imc.org offers a warm hug of welcome 188 S: 250 STARTTLS 189 C: STARTTLS 190 S: 220 Go ahead 191 C: 192 C & S: 193 C & S: 194 C: 195 . . . 197 7. Security Considerations 199 It should be noted that SMTP is not an end-to-end mechanism. Thus, if an 200 SMTP client/server pair decide to add TLS privacy, they are not securing 201 the transport from the originating mail user agent to the recipient. 202 Further, because delivery of a single piece of mail may go between more 203 than two SMTP servers, adding TLS privacy to one pair of servers does not 204 mean that the entire SMTP chain has been made private. Further, just 205 because an SMTP server can authenticate an SMTP client, it does not mean 206 that the mail from the SMTP client was authenticated by the SMTP client 207 when the client received it. 209 Both the STMP client and server must check the result of the TLS 210 negotiation to see whether acceptable authentication or privacy was 211 achieved. Ignoring this step completely invalidates using TLS for security. 212 The decision about whether acceptable authentication or privacy was 213 achieved is made locally, is implementation-dependant, and is beyond the 214 scope of this document. 216 The SMTP client and server should note carefully the result of the TLS 217 negotiation. If the negotiation results in no privacy, or if it results in 218 privacy using algorithms or key lengths that are deemed not strong 219 enough, or if the authentication is not good enough for either party, the 220 client may choose to end the SMTP session with an immediate QUIT command, 221 or the server may choose to not accept any more SMTP commands. 223 A server announcing in an EHLO response that it uses a particular TLS 224 protocol should not pose any security issues, since any use of TLS will be 225 at least as secure as no use of TLS. 227 A man-in-the-middle attack can be launched by deleting the "250 STARTTLS" 228 response from the server. This would cause the client not to try to start a 229 TLS session. An SMTP client can protect against this attack by recording 230 the fact that a particular SMTP server offers TLS during one session and 231 generating an alarm if it does not appear in the EHLO response for a later 232 session. The lack of TLS during a session SHOULD NOT result in the bouncing 233 of email, although it could result in delayed processing. 235 Before the TLS handshake has begun, any protocol interactions are performed 236 in the clear and may be modified by an active attacker. For this reason, 237 clients and servers MUST discard any knowledge obtained prior to the start 238 of the TLS handshake upon completion of the TLS handshake. 240 The STARTTLS extension is not suitable for authenticating the author of an 241 email message unless every hop in the delivery chain, including the 242 submission to the first SMTP server, is authenticated. Another proposal 243 [SMTP-AUTH] can be used to authenticate delivery and MIME security 244 multiparts [MIME-SEC] can be used to authenticate the author of an email 245 message. In addition, the [SMTP-AUTH] proposal offers simpler and more 246 flexible options to authenticate an SMTP client and the SASL EXTERNAL 247 mechanism [SASL] MAY be used in conjunction with the STARTTLS command to 248 provide an authorization identity. 250 A. References 252 [RFC-821] "Simple Mail Transfer Protocol", RFC 821 254 [RFC-1869] "SMTP Service Extensions", RFC 1869 256 [RFC-2034] "SMTP Service Extension for Returning Enhanced Error Codes", RFC 257 2034 259 [SASL] "Simple Authentication and Security Layer (SASL)", RFC 2222 261 [SMTP-AUTH] "SMTP Service Extension for Authentication", 262 Internet Draft draft-myers-smtp-auth-xx.txt 264 [TLS] "The TLS Protocol Version 1.0", draft-ietf-tls-protocol-xx.txt 266 B. Changes from -08 to -09 268 Removed previous appendix C about smtps port. A separate draft will cover 269 that topic. 271 C. Author's Address 273 Paul Hoffman 274 Internet Mail Consortium 275 127 Segre Place 276 Santa Cruz, CA 95060 277 (408) 426-9827 278 phoffman@imc.org