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