idnits 2.17.1 draft-hoffman-smtp-ssl-10.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-16) 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 284 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 53 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. 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 (November 6, 1998) is 9293 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 248 looks like a reference -- Missing reference section? 'TLS' on line 263 looks like a reference -- Missing reference section? 'RFC-2119' on line 255 looks like a reference -- Missing reference section? 'RFC-2034' on line 252 looks like a reference -- Missing reference section? 'SASL' on line 258 looks like a reference -- Missing reference section? 'SMTP-AUTH' on line 260 looks like a reference -- Missing reference section? 'MIME-SEC' on line 240 looks like a reference -- Missing reference section? 'RFC-1869' on line 250 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 10 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-10.txt Internet Mail Consortium 3 November 6, 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 Terminology 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC-2119]. 59 3. STARTTLS Extension 61 The STARTTLS extension to SMTP is laid out as follows: 63 (1) the name of the SMTP service defined here is STARTTLS; 65 (2) the EHLO keyword value associated with the extension is STARTTLS; 67 (3) the STARTTLS keyword has no parameters; 69 (4) a new SMTP verb, "STARTTLS", is defined; 71 (5) no additional parameters are added to any SMTP command. 73 4. The STARTTLS Keyword 75 The STARTTLS keyword is used to tell the SMTP client that the SMTP server 76 allows use of TLS. It takes no parameters. 78 5. The STARTTLS Command 80 The format for the STARTTLS command is: 82 STARTTLS 84 with no parameters. 86 After the client gives the STARTTLS command, the server responds with one 87 of the following reply codes: 89 220 Ready to start TLS 90 501 Syntax error (no parameters allowed) 91 454 TLS not available due to temporary reason 93 A publicly-referenced SMTP server MUST NOT require use of the STARTTLS 94 extension in order to deliver mail locally. This rule prevents the STARTTLS 95 extension from damaging the interoperability of the Internet's SMTP 96 infrastructure. A publicly-referenced SMTP server is an SMTP server which 97 runs on port 25 of an Internet host listed in the MX record (or A record if 98 an MX record is not present) for the domain name on the right hand side of 99 an Internet mail address. 101 Any SMTP server may refuse to accept messages for relay based on 102 authentication supplied during the TLS negotiation. An SMTP server that is 103 not publicly referenced may refuse to accept any messages for relay or 104 local delivery based on authentication supplied during the TLS negotiation. 106 A SMTP server that is not publicly referenced may choose to require that 107 the client perform a TLS negotiation before accepting any commands. In this 108 case, the server SHOULD return the reply code: 110 530 Must issue a STARTTLS command first 112 to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the client 113 and server are using the ENHANCEDSTATUSCODES ESMTP extension [RFC-2034], 114 the status code to be returned SHOULD be 5.7.0. 116 After receiving a 220 response to a STARTTLS command, the client SHOULD 117 start the TLS negotiation before giving any other SMTP commands. 119 If the SMTP client is using pipelining as defined in RFC 1854, the STARTTLS 120 command must be the last command in a group. 122 5.1 Processing After the STARTTLS Command 124 After the TLS handshake has been completed, both parties MUST immediately 125 decide whether or not to continue based on the authentication and privacy 126 achieved. The SMTP client and server may decide to move ahead even if the 127 TLS negotiation ended with no authentication and/or no privacy because most 128 SMTP services are performed with no authentication and no privacy, but some 129 SMTP clients or servers may want to continue only if a particular level of 130 authentication and/or privacy was achieved. 132 If the SMTP client decides that the level of authentication or privacy is 133 not high enough for it to continue, it SHOULD issue an SMTP QUIT command 134 immediately after the TLS negotiation is complete. If the SMTP server 135 decides that the level of authentication or privacy is not high enough for 136 it to continue, it SHOULD reply to every SMTP command from the client 137 (other than a QUIT command) with the 554 reply code (with a possible text 138 string such as "Command refused due to lack of security"). 140 The decision of whether or not to believe the authenticity of the other 141 party in a TLS negotiation is a local matter. However, some general rules 142 for the decisions are: 143 - A SMTP client would probably only want to authenticate an SMTP 144 server whose server certificate has a domain name that is the 145 domain name that the client thought it was connecting to. 146 - A publicly-referenced SMTP server would probably want to accept 147 any certificate from an SMTP client, and would possibly want to 148 put distinguishing information about the certificate in the 149 Received header of messages that were relayed or submitted from 150 the client. 152 5.2 Result of the STARTTLS Command 154 Upon completion of the TLS handshake, the SMTP protocol is reset to the 155 initial state (the state in SMTP after a server issues a 220 service ready 156 greeting). The server MUST discard any knowledge obtained from the client, 157 such as the argument to the EHLO command, which was not obtained from the 158 TLS negotiation itself. The client MUST discard any knowledge obtained from 159 the server, such as the list of SMTP service extensions, which was not 160 obtained from the TLS negotiation itself. The client SHOULD send an EHLO 161 command as the first command after a successful TLS negotiation. 163 The list of SMTP service extensions returned in response to an EHLO command 164 received after the TLS handshake MAY be different than the list returned 165 before the TLS handshake. For example, an SMTP server might not want to 166 advertise support for a particular SASL mechanism [SASL] unless a client 167 has sent an appropriate client certificate during a TLS handshake. 169 Both the client and the server MUST know if there is a TLS session active. 170 A client MUST NOT attempt to start a TLS session if a TLS session is 171 already active. A server MUST NOT return the TLS extension in response to 172 an EHLO command received after a TLS handshake has completed. 174 6. Usage Example 176 The following dialog illustrates how a client and server can start a TLS 177 session: 179 S: 180 C: 181 S: 220 mail.imc.org SMTP service ready 182 C: EHLO mail.ietf.org 183 S: 250-mail.imc.org offers a warm hug of welcome 184 S: 250 STARTTLS 185 C: STARTTLS 186 S: 220 Go ahead 187 C: 188 C & S: 189 C & S: 190 C: 191 . . . 193 7. Security Considerations 195 It should be noted that SMTP is not an end-to-end mechanism. Thus, if an 196 SMTP client/server pair decide to add TLS privacy, they are not securing 197 the transport from the originating mail user agent to the recipient. 198 Further, because delivery of a single piece of mail may go between more 199 than two SMTP servers, adding TLS privacy to one pair of servers does not 200 mean that the entire SMTP chain has been made private. Further, just 201 because an SMTP server can authenticate an SMTP client, it does not mean 202 that the mail from the SMTP client was authenticated by the SMTP client 203 when the client received it. 205 Both the STMP client and server must check the result of the TLS 206 negotiation to see whether acceptable authentication or privacy was 207 achieved. Ignoring this step completely invalidates using TLS for security. 208 The decision about whether acceptable authentication or privacy was 209 achieved is made locally, is implementation-dependant, and is beyond the 210 scope of this document. 212 The SMTP client and server should note carefully the result of the TLS 213 negotiation. If the negotiation results in no privacy, or if it results in 214 privacy using algorithms or key lengths that are deemed not strong 215 enough, or if the authentication is not good enough for either party, the 216 client may choose to end the SMTP session with an immediate QUIT command, 217 or the server may choose to not accept any more SMTP commands. 219 A server announcing in an EHLO response that it uses a particular TLS 220 protocol should not pose any security issues, since any use of TLS will be 221 at least as secure as no use of TLS. 223 A man-in-the-middle attack can be launched by deleting the "250 STARTTLS" 224 response from the server. This would cause the client not to try to start a 225 TLS session. An SMTP client can protect against this attack by recording 226 the fact that a particular SMTP server offers TLS during one session and 227 generating an alarm if it does not appear in the EHLO response for a later 228 session. The lack of TLS during a session SHOULD NOT result in the bouncing 229 of email, although it could result in delayed processing. 231 Before the TLS handshake has begun, any protocol interactions are performed 232 in the clear and may be modified by an active attacker. For this reason, 233 clients and servers MUST discard any knowledge obtained prior to the start 234 of the TLS handshake upon completion of the TLS handshake. 236 The STARTTLS extension is not suitable for authenticating the author of an 237 email message unless every hop in the delivery chain, including the 238 submission to the first SMTP server, is authenticated. Another proposal 239 [SMTP-AUTH] can be used to authenticate delivery and MIME security 240 multiparts [MIME-SEC] can be used to authenticate the author of an email 241 message. In addition, the [SMTP-AUTH] proposal offers simpler and more 242 flexible options to authenticate an SMTP client and the SASL EXTERNAL 243 mechanism [SASL] MAY be used in conjunction with the STARTTLS command to 244 provide an authorization identity. 246 A. References 248 [RFC-821] "Simple Mail Transfer Protocol", RFC 821 250 [RFC-1869] "SMTP Service Extensions", RFC 1869 252 [RFC-2034] "SMTP Service Extension for Returning Enhanced Error Codes", RFC 253 2034 255 [RFC-2119] "Key words for use in RFCs to Indicate Requirement Levels", 256 BCP 14, RFC 2119 258 [SASL] "Simple Authentication and Security Layer (SASL)", RFC 2222 260 [SMTP-AUTH] "SMTP Service Extension for Authentication", 261 Internet Draft draft-myers-smtp-auth-xx.txt 263 [TLS] "The TLS Protocol Version 1.0", draft-ietf-tls-protocol-xx.txt 265 B. Author's Address 267 Paul Hoffman 268 Internet Mail Consortium 269 127 Segre Place 270 Santa Cruz, CA 95060 271 (408) 426-9827 272 phoffman@imc.org