Load cups into easysw/current.
[thirdparty/cups.git] / standards / rfc2487.txt
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