]>
Commit | Line | Data |
---|---|---|
ef416fc2 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group P. Hoffman | |
8 | Request for Comments: 2487 Internet Mail Consortium | |
9 | Category: Standards Track January 1999 | |
10 | ||
11 | ||
12 | SMTP Service Extension for Secure SMTP over TLS | |
13 | ||
14 | Status of this Memo | |
15 | ||
16 | This document specifies an Internet standards track protocol for the | |
17 | Internet community, and requests discussion and suggestions for | |
18 | improvements. Please refer to the current edition of the "Internet | |
19 | Official Protocol Standards" (STD 1) for the standardization state | |
20 | and status of this protocol. Distribution of this memo is unlimited. | |
21 | ||
22 | Copyright Notice | |
23 | ||
24 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
25 | ||
26 | 1. Abstract | |
27 | ||
28 | This document describes an extension to the SMTP service that allows | |
29 | an SMTP server and client to use transport-layer security to provide | |
30 | private, authenticated communication over the Internet. This gives | |
31 | SMTP agents the ability to protect some or all of their | |
32 | communications from eavesdroppers and attackers. | |
33 | ||
34 | 2. Introduction | |
35 | ||
36 | SMTP [RFC-821] servers and clients normally communicate in the clear | |
37 | over the Internet. In many cases, this communication goes through one | |
38 | or more router that is not controlled or trusted by either entity. | |
39 | Such an untrusted router might allow a third party to monitor or | |
40 | alter the communications between the server and client. | |
41 | ||
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 | |
44 | server might only allow communications from other SMTP agents it | |
45 | knows, or it might act differently for messages received from an | |
46 | agent it knows than from one it doesn't know. | |
47 | ||
48 | TLS [TLS], more commonly known as SSL, is a popular mechanism for | |
49 | enhancing TCP communications with privacy and authentication. TLS is | |
50 | in wide use with the HTTP protocol, and is also being used for adding | |
51 | security to many other common protocols that run over TCP. | |
52 | ||
53 | ||
54 | ||
55 | ||
56 | ||
57 | ||
58 | Hoffman Standards Track [Page 1] | |
59 | \f | |
60 | RFC 2487 SMTP Service Extension January 1999 | |
61 | ||
62 | ||
63 | 2.1 Terminology | |
64 | ||
65 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
66 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |
67 | document are to be interpreted as described in [RFC-2119]. | |
68 | ||
69 | 3. STARTTLS Extension | |
70 | ||
71 | The STARTTLS extension to SMTP is laid out as follows: | |
72 | ||
73 | (1) the name of the SMTP service defined here is STARTTLS; | |
74 | ||
75 | (2) the EHLO keyword value associated with the extension is STARTTLS; | |
76 | ||
77 | (3) the STARTTLS keyword has no parameters; | |
78 | ||
79 | (4) a new SMTP verb, "STARTTLS", is defined; | |
80 | ||
81 | (5) no additional parameters are added to any SMTP command. | |
82 | ||
83 | 4. The STARTTLS Keyword | |
84 | ||
85 | The STARTTLS keyword is used to tell the SMTP client that the SMTP | |
86 | server allows use of TLS. It takes no parameters. | |
87 | ||
88 | 5. The STARTTLS Command | |
89 | ||
90 | The format for the STARTTLS command is: | |
91 | ||
92 | STARTTLS | |
93 | ||
94 | with no parameters. | |
95 | ||
96 | After the client gives the STARTTLS command, the server responds with | |
97 | one of the following reply codes: | |
98 | ||
99 | 220 Ready to start TLS | |
100 | 501 Syntax error (no parameters allowed) | |
101 | 454 TLS not available due to temporary reason | |
102 | ||
103 | A publicly-referenced SMTP server MUST NOT require use of the | |
104 | STARTTLS extension in order to deliver mail locally. This rule | |
105 | prevents the STARTTLS extension from damaging the interoperability of | |
106 | the Internet's SMTP infrastructure. A publicly-referenced SMTP server | |
107 | is an SMTP server which runs on port 25 of an Internet host listed in | |
108 | the MX record (or A record if an MX record is not present) for the | |
109 | domain name on the right hand side of an Internet mail address. | |
110 | ||
111 | ||
112 | ||
113 | ||
114 | Hoffman Standards Track [Page 2] | |
115 | \f | |
116 | RFC 2487 SMTP Service Extension January 1999 | |
117 | ||
118 | ||
119 | Any SMTP server may refuse to accept messages for relay based on | |
120 | authentication supplied during the TLS negotiation. An SMTP server | |
121 | that is not publicly referenced may refuse to accept any messages for | |
122 | relay or local delivery based on authentication supplied during the | |
123 | TLS negotiation. | |
124 | ||
125 | A SMTP server that is not publicly referenced may choose to require | |
126 | that the client perform a TLS negotiation before accepting any | |
127 | commands. In this case, the server SHOULD return the reply code: | |
128 | ||
129 | 530 Must issue a STARTTLS command first | |
130 | ||
131 | to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the | |
132 | client and server are using the ENHANCEDSTATUSCODES ESMTP extension | |
133 | [RFC-2034], the status code to be returned SHOULD be 5.7.0. | |
134 | ||
135 | After receiving a 220 response to a STARTTLS command, the client | |
136 | SHOULD start the TLS negotiation before giving any other SMTP | |
137 | commands. | |
138 | ||
139 | If the SMTP client is using pipelining as defined in RFC 1854, the | |
140 | STARTTLS command must be the last command in a group. | |
141 | ||
142 | 5.1 Processing After the STARTTLS Command | |
143 | ||
144 | After the TLS handshake has been completed, both parties MUST | |
145 | immediately decide whether or not to continue based on the | |
146 | authentication and privacy achieved. The SMTP client and server may | |
147 | decide to move ahead even if the TLS negotiation ended with no | |
148 | authentication and/or no privacy because most SMTP services are | |
149 | performed with no authentication and no privacy, but some SMTP | |
150 | clients or servers may want to continue only if a particular level of | |
151 | authentication and/or privacy was achieved. | |
152 | ||
153 | If the SMTP client decides that the level of authentication or | |
154 | privacy is not high enough for it to continue, it SHOULD issue an | |
155 | SMTP QUIT command immediately after the TLS negotiation is complete. | |
156 | If the SMTP server decides that the level of authentication or | |
157 | privacy is not high enough for it to continue, it SHOULD reply to | |
158 | every SMTP command from the client (other than a QUIT command) with | |
159 | the 554 reply code (with a possible text string such as "Command | |
160 | refused due to lack of security"). | |
161 | ||
162 | The decision of whether or not to believe the authenticity of the | |
163 | other party in a TLS negotiation is a local matter. However, some | |
164 | general rules for the decisions are: | |
165 | ||
166 | ||
167 | ||
168 | ||
169 | ||
170 | Hoffman Standards Track [Page 3] | |
171 | \f | |
172 | RFC 2487 SMTP Service Extension January 1999 | |
173 | ||
174 | ||
175 | - A SMTP client would probably only want to authenticate an SMTP | |
176 | server whose server certificate has a domain name that is the | |
177 | domain name that the client thought it was connecting to. | |
178 | - A publicly-referenced SMTP server would probably want to accept | |
179 | any certificate from an SMTP client, and would possibly want to | |
180 | put distinguishing information about the certificate in the | |
181 | Received header of messages that were relayed or submitted from | |
182 | the client. | |
183 | ||
184 | 5.2 Result of the STARTTLS Command | |
185 | ||
186 | Upon completion of the TLS handshake, the SMTP protocol is reset to | |
187 | the initial state (the state in SMTP after a server issues a 220 | |
188 | service ready greeting). The server MUST discard any knowledge | |
189 | obtained from the client, such as the argument to the EHLO command, | |
190 | which was not obtained from the TLS negotiation itself. The client | |
191 | MUST discard any knowledge obtained from the server, such as the list | |
192 | of SMTP service extensions, which was not obtained from the TLS | |
193 | negotiation itself. The client SHOULD send an EHLO command as the | |
194 | first command after a successful TLS negotiation. | |
195 | ||
196 | The list of SMTP service extensions returned in response to an EHLO | |
197 | command received after the TLS handshake MAY be different than the | |
198 | list returned before the TLS handshake. For example, an SMTP server | |
199 | might not want to advertise support for a particular SASL mechanism | |
200 | [SASL] unless a client has sent an appropriate client certificate | |
201 | during a TLS handshake. | |
202 | ||
203 | Both the client and the server MUST know if there is a TLS session | |
204 | active. A client MUST NOT attempt to start a TLS session if a TLS | |
205 | session is already active. A server MUST NOT return the TLS extension | |
206 | in response to an EHLO command received after a TLS handshake has | |
207 | completed. | |
208 | ||
209 | 6. Usage Example | |
210 | ||
211 | The following dialog illustrates how a client and server can start a | |
212 | TLS session: | |
213 | ||
214 | S: <waits for connection on TCP port 25> | |
215 | C: <opens connection> | |
216 | S: 220 mail.imc.org SMTP service ready | |
217 | C: EHLO mail.ietf.org | |
218 | S: 250-mail.imc.org offers a warm hug of welcome | |
219 | S: 250 STARTTLS | |
220 | C: STARTTLS | |
221 | S: 220 Go ahead | |
222 | C: <starts TLS negotiation> | |
223 | ||
224 | ||
225 | ||
226 | Hoffman Standards Track [Page 4] | |
227 | \f | |
228 | RFC 2487 SMTP Service Extension January 1999 | |
229 | ||
230 | ||
231 | C & S: <negotiate a TLS session> | |
232 | C & S: <check result of negotiation> | |
233 | C: <continues by sending an SMTP command> | |
234 | . . . | |
235 | ||
236 | 7. Security Considerations | |
237 | ||
238 | It should be noted that SMTP is not an end-to-end mechanism. Thus, if | |
239 | an SMTP client/server pair decide to add TLS privacy, they are not | |
240 | securing the transport from the originating mail user agent to the | |
241 | recipient. Further, because delivery of a single piece of mail may | |
242 | go between more than two SMTP servers, adding TLS privacy to one pair | |
243 | of servers does not mean that the entire SMTP chain has been made | |
244 | private. Further, just because an SMTP server can authenticate an | |
245 | SMTP client, it does not mean that the mail from the SMTP client was | |
246 | authenticated by the SMTP client when the client received it. | |
247 | ||
248 | Both the STMP client and server must check the result of the TLS | |
249 | negotiation to see whether acceptable authentication or privacy was | |
250 | achieved. Ignoring this step completely invalidates using TLS for | |
251 | security. The decision about whether acceptable authentication or | |
252 | privacy was achieved is made locally, is implementation-dependant, | |
253 | and is beyond the scope of this document. | |
254 | ||
255 | The SMTP client and server should note carefully the result of the | |
256 | TLS negotiation. If the negotiation results in no privacy, or if it | |
257 | results in privacy using algorithms or key lengths that are deemed | |
258 | not strong enough, or if the authentication is not good enough for | |
259 | either party, the client may choose to end the SMTP session with an | |
260 | immediate QUIT command, or the server may choose to not accept any | |
261 | more SMTP commands. | |
262 | ||
263 | A server announcing in an EHLO response that it uses a particular TLS | |
264 | protocol should not pose any security issues, since any use of TLS | |
265 | will be at least as secure as no use of TLS. | |
266 | ||
267 | A man-in-the-middle attack can be launched by deleting the "250 | |
268 | STARTTLS" response from the server. This would cause the client not | |
269 | to try to start a TLS session. An SMTP client can protect against | |
270 | this attack by recording the fact that a particular SMTP server | |
271 | offers TLS during one session and generating an alarm if it does not | |
272 | appear in the EHLO response for a later session. The lack of TLS | |
273 | during a session SHOULD NOT result in the bouncing of email, although | |
274 | it could result in delayed processing. | |
275 | ||
276 | ||
277 | ||
278 | ||
279 | ||
280 | ||
281 | ||
282 | Hoffman Standards Track [Page 5] | |
283 | \f | |
284 | RFC 2487 SMTP Service Extension January 1999 | |
285 | ||
286 | ||
287 | Before the TLS handshake has begun, any protocol interactions are | |
288 | performed in the clear and may be modified by an active attacker. For | |
289 | this reason, clients and servers MUST discard any knowledge obtained | |
290 | prior to the start of the TLS handshake upon completion of the TLS | |
291 | handshake. | |
292 | ||
293 | The STARTTLS extension is not suitable for authenticating the author | |
294 | of an email message unless every hop in the delivery chain, including | |
295 | the submission to the first SMTP server, is authenticated. Another | |
296 | proposal [SMTP-AUTH] can be used to authenticate delivery and MIME | |
297 | security multiparts [MIME-SEC] can be used to authenticate the author | |
298 | of an email message. In addition, the [SMTP-AUTH] proposal offers | |
299 | simpler and more flexible options to authenticate an SMTP client and | |
300 | the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with | |
301 | the STARTTLS command to provide an authorization identity. | |
302 | ||
303 | ||
304 | ||
305 | ||
306 | ||
307 | ||
308 | ||
309 | ||
310 | ||
311 | ||
312 | ||
313 | ||
314 | ||
315 | ||
316 | ||
317 | ||
318 | ||
319 | ||
320 | ||
321 | ||
322 | ||
323 | ||
324 | ||
325 | ||
326 | ||
327 | ||
328 | ||
329 | ||
330 | ||
331 | ||
332 | ||
333 | ||
334 | ||
335 | ||
336 | ||
337 | ||
338 | Hoffman Standards Track [Page 6] | |
339 | \f | |
340 | RFC 2487 SMTP Service Extension January 1999 | |
341 | ||
342 | ||
343 | A. References | |
344 | ||
345 | [RFC-821] Postel, J., "Simple Mail Transfer Protocol", RFC 821, | |
346 | August 1982. | |
347 | ||
348 | [RFC-1869] Klensin, J., Freed, N, Rose, M, Stefferud, E. and D. | |
349 | Crocker, "SMTP Service Extensions", STD 10, RFC 1869, | |
350 | November 1995. | |
351 | ||
352 | [RFC-2034] Freed, N., "SMTP Service Extension for Returning Enhanced | |
353 | Error Codes", RFC 2034, October 1996. | |
354 | ||
355 | [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate | |
356 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
357 | ||
358 | [SASL] Myers, J., "Simple Authentication and Security Layer | |
359 | (SASL)", RFC 2222, October 1997. | |
360 | ||
361 | [SMTP-AUTH] "SMTP Service Extension for Authentication", Work in | |
362 | Progress. | |
363 | ||
364 | [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", | |
365 | RFC 2246, January 1999. | |
366 | ||
367 | B. Author's Address | |
368 | ||
369 | Paul Hoffman | |
370 | Internet Mail Consortium | |
371 | 127 Segre Place | |
372 | Santa Cruz, CA 95060 | |
373 | ||
374 | Phone: (831) 426-9827 | |
375 | EMail: phoffman@imc.org | |
376 | ||
377 | ||
378 | ||
379 | ||
380 | ||
381 | ||
382 | ||
383 | ||
384 | ||
385 | ||
386 | ||
387 | ||
388 | ||
389 | ||
390 | ||
391 | ||
392 | ||
393 | ||
394 | Hoffman Standards Track [Page 7] | |
395 | \f | |
396 | RFC 2487 SMTP Service Extension January 1999 | |
397 | ||
398 | ||
399 | C. Full Copyright Statement | |
400 | ||
401 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
402 | ||
403 | This document and translations of it may be copied and furnished to | |
404 | others, and derivative works that comment on or otherwise explain it | |
405 | or assist in its implementation may be prepared, copied, published | |
406 | and distributed, in whole or in part, without restriction of any | |
407 | kind, provided that the above copyright notice and this paragraph are | |
408 | included on all such copies and derivative works. However, this | |
409 | document itself may not be modified in any way, such as by removing | |
410 | the copyright notice or references to the Internet Society or other | |
411 | Internet organizations, except as needed for the purpose of | |
412 | developing Internet standards in which case the procedures for | |
413 | copyrights defined in the Internet Standards process must be | |
414 | followed, or as required to translate it into languages other than | |
415 | English. | |
416 | ||
417 | The limited permissions granted above are perpetual and will not be | |
418 | revoked by the Internet Society or its successors or assigns. | |
419 | ||
420 | This document and the information contained herein is provided on an | |
421 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
422 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
423 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
424 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
425 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
426 | ||
427 | ||
428 | ||
429 | ||
430 | ||
431 | ||
432 | ||
433 | ||
434 | ||
435 | ||
436 | ||
437 | ||
438 | ||
439 | ||
440 | ||
441 | ||
442 | ||
443 | ||
444 | ||
445 | ||
446 | ||
447 | ||
448 | ||
449 | ||
450 | Hoffman Standards Track [Page 8] | |
451 | \f |