]>
Commit | Line | Data |
---|---|---|
ef416fc2 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group C. Newman | |
8 | Request for Comments: 2595 Innosoft | |
9 | Category: Standards Track June 1999 | |
10 | ||
11 | ||
12 | Using TLS with IMAP, POP3 and ACAP | |
13 | ||
14 | ||
15 | Status of this Memo | |
16 | ||
17 | This document specifies an Internet standards track protocol for the | |
18 | Internet community, and requests discussion and suggestions for | |
19 | improvements. Please refer to the current edition of the "Internet | |
20 | Official Protocol Standards" (STD 1) for the standardization state | |
21 | and status of this protocol. Distribution of this memo is unlimited. | |
22 | ||
23 | Copyright Notice | |
24 | ||
25 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
26 | ||
27 | 1. Motivation | |
28 | ||
29 | The TLS protocol (formerly known as SSL) provides a way to secure an | |
30 | application protocol from tampering and eavesdropping. The option of | |
31 | using such security is desirable for IMAP, POP and ACAP due to common | |
32 | connection eavesdropping and hijacking attacks [AUTH]. Although | |
33 | advanced SASL authentication mechanisms can provide a lightweight | |
34 | version of this service, TLS is complimentary to simple | |
35 | authentication-only SASL mechanisms or deployed clear-text password | |
36 | login commands. | |
37 | ||
38 | Many sites have a high investment in authentication infrastructure | |
39 | (e.g., a large database of a one-way-function applied to user | |
40 | passwords), so a privacy layer which is not tightly bound to user | |
41 | authentication can protect against network eavesdropping attacks | |
42 | without requiring a new authentication infrastructure and/or forcing | |
43 | all users to change their password. Recognizing that such sites will | |
44 | desire simple password authentication in combination with TLS | |
45 | encryption, this specification defines the PLAIN SASL mechanism for | |
46 | use with protocols which lack a simple password authentication | |
47 | command such as ACAP and SMTP. (Note there is a separate RFC for the | |
48 | STARTTLS command in SMTP [SMTPTLS].) | |
49 | ||
50 | There is a strong desire in the IETF to eliminate the transmission of | |
51 | clear-text passwords over unencrypted channels. While SASL can be | |
52 | used for this purpose, TLS provides an additional tool with different | |
53 | deployability characteristics. A server supporting both TLS with | |
54 | ||
55 | ||
56 | ||
57 | ||
58 | Newman Standards Track [Page 1] | |
59 | \f | |
60 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
61 | ||
62 | ||
63 | simple passwords and a challenge/response SASL mechanism is likely to | |
64 | interoperate with a wide variety of clients without resorting to | |
65 | unencrypted clear-text passwords. | |
66 | ||
67 | The STARTTLS command rectifies a number of the problems with using a | |
68 | separate port for a "secure" protocol variant. Some of these are | |
69 | mentioned in section 7. | |
70 | ||
71 | 1.1. Conventions Used in this Document | |
72 | ||
73 | The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", | |
74 | "MAY", and "OPTIONAL" in this document are to be interpreted as | |
75 | described in "Key words for use in RFCs to Indicate Requirement | |
76 | Levels" [KEYWORDS]. | |
77 | ||
78 | Terms related to authentication are defined in "On Internet | |
79 | Authentication" [AUTH]. | |
80 | ||
81 | Formal syntax is defined using ABNF [ABNF]. | |
82 | ||
83 | In examples, "C:" and "S:" indicate lines sent by the client and | |
84 | server respectively. | |
85 | ||
86 | 2. Basic Interoperability and Security Requirements | |
87 | ||
88 | The following requirements apply to all implementations of the | |
89 | STARTTLS extension for IMAP, POP3 and ACAP. | |
90 | ||
91 | 2.1. Cipher Suite Requirements | |
92 | ||
93 | Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher | |
94 | suite is REQUIRED. This is important as it assures that any two | |
95 | compliant implementations can be configured to interoperate. | |
96 | ||
97 | All other cipher suites are OPTIONAL. | |
98 | ||
99 | 2.2. Privacy Operational Mode Security Requirements | |
100 | ||
101 | Both clients and servers SHOULD have a privacy operational mode which | |
102 | refuses authentication unless successful activation of an encryption | |
103 | layer (such as that provided by TLS) occurs prior to or at the time | |
104 | of authentication and which will terminate the connection if that | |
105 | encryption layer is deactivated. Implementations are encouraged to | |
106 | have flexability with respect to the minimal encryption strength or | |
107 | cipher suites permitted. A minimalist approach to this | |
108 | recommendation would be an operational mode where the | |
109 | TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to | |
110 | permitting authentication. | |
111 | ||
112 | ||
113 | ||
114 | Newman Standards Track [Page 2] | |
115 | \f | |
116 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
117 | ||
118 | ||
119 | Clients MAY have an operational mode which uses encryption only when | |
120 | it is advertised by the server, but authentication continues | |
121 | regardless. For backwards compatibility, servers SHOULD have an | |
122 | operational mode where only the authentication mechanisms required by | |
123 | the relevant base protocol specification are needed to successfully | |
124 | authenticate. | |
125 | ||
126 | 2.3. Clear-Text Password Requirements | |
127 | ||
128 | Clients and servers which implement STARTTLS MUST be configurable to | |
129 | refuse all clear-text login commands or mechanisms (including both | |
130 | standards-track and nonstandard mechanisms) unless an encryption | |
131 | layer of adequate strength is active. Servers which allow | |
132 | unencrypted clear-text logins SHOULD be configurable to refuse | |
133 | clear-text logins both for the entire server, and on a per-user | |
134 | basis. | |
135 | ||
136 | 2.4. Server Identity Check | |
137 | ||
138 | During the TLS negotiation, the client MUST check its understanding | |
139 | of the server hostname against the server's identity as presented in | |
140 | the server Certificate message, in order to prevent man-in-the-middle | |
141 | attacks. Matching is performed according to these rules: | |
142 | ||
143 | - The client MUST use the server hostname it used to open the | |
144 | connection as the value to compare against the server name as | |
145 | expressed in the server certificate. The client MUST NOT use any | |
146 | form of the server hostname derived from an insecure remote source | |
147 | (e.g., insecure DNS lookup). CNAME canonicalization is not done. | |
148 | ||
149 | - If a subjectAltName extension of type dNSName is present in the | |
150 | certificate, it SHOULD be used as the source of the server's | |
151 | identity. | |
152 | ||
153 | - Matching is case-insensitive. | |
154 | ||
155 | - A "*" wildcard character MAY be used as the left-most name | |
156 | component in the certificate. For example, *.example.com would | |
157 | match a.example.com, foo.example.com, etc. but would not match | |
158 | example.com. | |
159 | ||
160 | - If the certificate contains multiple names (e.g. more than one | |
161 | dNSName field), then a match with any one of the fields is | |
162 | considered acceptable. | |
163 | ||
164 | If the match fails, the client SHOULD either ask for explicit user | |
165 | confirmation, or terminate the connection and indicate the server's | |
166 | identity is suspect. | |
167 | ||
168 | ||
169 | ||
170 | Newman Standards Track [Page 3] | |
171 | \f | |
172 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
173 | ||
174 | ||
175 | 2.5. TLS Security Policy Check | |
176 | ||
177 | Both the client and server MUST check the result of the STARTTLS | |
178 | command and subsequent TLS negotiation to see whether acceptable | |
179 | authentication or privacy was achieved. Ignoring this step | |
180 | completely invalidates using TLS for security. The decision about | |
181 | whether acceptable authentication or privacy was achieved is made | |
182 | locally, is implementation-dependent, and is beyond the scope of this | |
183 | document. | |
184 | ||
185 | 3. IMAP STARTTLS extension | |
186 | ||
187 | When the TLS extension is present in IMAP, "STARTTLS" is listed as a | |
188 | capability in response to the CAPABILITY command. This extension | |
189 | adds a single command, "STARTTLS" to the IMAP protocol which is used | |
190 | to begin a TLS negotiation. | |
191 | ||
192 | 3.1. STARTTLS Command | |
193 | ||
194 | Arguments: none | |
195 | ||
196 | Responses: no specific responses for this command | |
197 | ||
198 | Result: OK - begin TLS negotiation | |
199 | BAD - command unknown or arguments invalid | |
200 | ||
201 | A TLS negotiation begins immediately after the CRLF at the end of | |
202 | the tagged OK response from the server. Once a client issues a | |
203 | STARTTLS command, it MUST NOT issue further commands until a | |
204 | server response is seen and the TLS negotiation is complete. | |
205 | ||
206 | The STARTTLS command is only valid in non-authenticated state. | |
207 | The server remains in non-authenticated state, even if client | |
208 | credentials are supplied during the TLS negotiation. The SASL | |
209 | [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS | |
210 | client credentials are successfully exchanged, but servers | |
211 | supporting the STARTTLS command are not required to support the | |
212 | EXTERNAL mechanism. | |
213 | ||
214 | Once TLS has been started, the client MUST discard cached | |
215 | information about server capabilities and SHOULD re-issue the | |
216 | CAPABILITY command. This is necessary to protect against | |
217 | man-in-the-middle attacks which alter the capabilities list prior | |
218 | to STARTTLS. The server MAY advertise different capabilities | |
219 | after STARTTLS. | |
220 | ||
221 | The formal syntax for IMAP is amended as follows: | |
222 | ||
223 | ||
224 | ||
225 | ||
226 | Newman Standards Track [Page 4] | |
227 | \f | |
228 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
229 | ||
230 | ||
231 | command_any =/ "STARTTLS" | |
232 | ||
233 | Example: C: a001 CAPABILITY | |
234 | S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED | |
235 | S: a001 OK CAPABILITY completed | |
236 | C: a002 STARTTLS | |
237 | S: a002 OK Begin TLS negotiation now | |
238 | <TLS negotiation, further commands are under TLS layer> | |
239 | C: a003 CAPABILITY | |
240 | S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL | |
241 | S: a003 OK CAPABILITY completed | |
242 | C: a004 LOGIN joe password | |
243 | S: a004 OK LOGIN completed | |
244 | ||
245 | 3.2. IMAP LOGINDISABLED capability | |
246 | ||
247 | The current IMAP protocol specification (RFC 2060) requires the | |
248 | implementation of the LOGIN command which uses clear-text passwords. | |
249 | Many sites may choose to disable this command unless encryption is | |
250 | active for security reasons. An IMAP server MAY advertise that the | |
251 | LOGIN command is disabled by including the LOGINDISABLED capability | |
252 | in the capability response. Such a server will respond with a tagged | |
253 | "NO" response to any attempt to use the LOGIN command. | |
254 | ||
255 | An IMAP server which implements STARTTLS MUST implement support for | |
256 | the LOGINDISABLED capability on unencrypted connections. | |
257 | ||
258 | An IMAP client which complies with this specification MUST NOT issue | |
259 | the LOGIN command if this capability is present. | |
260 | ||
261 | This capability is useful to prevent clients compliant with this | |
262 | specification from sending an unencrypted password in an environment | |
263 | subject to passive attacks. It has no impact on an environment | |
264 | subject to active attacks as a man-in-the-middle attacker can remove | |
265 | this capability. Therefore this does not relieve clients of the need | |
266 | to follow the privacy mode recommendation in section 2.2. | |
267 | ||
268 | Servers advertising this capability will fail to interoperate with | |
269 | many existing compliant IMAP clients and will be unable to prevent | |
270 | those clients from disclosing the user's password. | |
271 | ||
272 | 4. POP3 STARTTLS extension | |
273 | ||
274 | The POP3 STARTTLS extension adds the STLS command to POP3 servers. | |
275 | If this is implemented, the POP3 extension mechanism [POP3EXT] MUST | |
276 | also be implemented to avoid the need for client probing of multiple | |
277 | commands. The capability name "STLS" indicates this command is | |
278 | present and permitted in the current state. | |
279 | ||
280 | ||
281 | ||
282 | Newman Standards Track [Page 5] | |
283 | \f | |
284 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
285 | ||
286 | ||
287 | STLS | |
288 | ||
289 | Arguments: none | |
290 | ||
291 | Restrictions: | |
292 | Only permitted in AUTHORIZATION state. | |
293 | ||
294 | Discussion: | |
295 | A TLS negotiation begins immediately after the CRLF at the | |
296 | end of the +OK response from the server. A -ERR response | |
297 | MAY result if a security layer is already active. Once a | |
298 | client issues a STLS command, it MUST NOT issue further | |
299 | commands until a server response is seen and the TLS | |
300 | negotiation is complete. | |
301 | ||
302 | The STLS command is only permitted in AUTHORIZATION state | |
303 | and the server remains in AUTHORIZATION state, even if | |
304 | client credentials are supplied during the TLS negotiation. | |
305 | The AUTH command [POP-AUTH] with the EXTERNAL mechanism | |
306 | [SASL] MAY be used to authenticate once TLS client | |
307 | credentials are successfully exchanged, but servers | |
308 | supporting the STLS command are not required to support the | |
309 | EXTERNAL mechanism. | |
310 | ||
311 | Once TLS has been started, the client MUST discard cached | |
312 | information about server capabilities and SHOULD re-issue | |
313 | the CAPA command. This is necessary to protect against | |
314 | man-in-the-middle attacks which alter the capabilities list | |
315 | prior to STLS. The server MAY advertise different | |
316 | capabilities after STLS. | |
317 | ||
318 | Possible Responses: | |
319 | +OK -ERR | |
320 | ||
321 | Examples: | |
322 | C: STLS | |
323 | S: +OK Begin TLS negotiation | |
324 | <TLS negotiation, further commands are under TLS layer> | |
325 | ... | |
326 | C: STLS | |
327 | S: -ERR Command not permitted when TLS active | |
328 | ||
329 | ||
330 | ||
331 | ||
332 | ||
333 | ||
334 | ||
335 | ||
336 | ||
337 | ||
338 | Newman Standards Track [Page 6] | |
339 | \f | |
340 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
341 | ||
342 | ||
343 | 5. ACAP STARTTLS extension | |
344 | ||
345 | When the TLS extension is present in ACAP, "STARTTLS" is listed as a | |
346 | capability in the ACAP greeting. No arguments to this capability are | |
347 | defined at this time. This extension adds a single command, | |
348 | "STARTTLS" to the ACAP protocol which is used to begin a TLS | |
349 | negotiation. | |
350 | ||
351 | 5.1. STARTTLS Command | |
352 | ||
353 | Arguments: none | |
354 | ||
355 | Responses: no specific responses for this command | |
356 | ||
357 | Result: OK - begin TLS negotiation | |
358 | BAD - command unknown or arguments invalid | |
359 | ||
360 | A TLS negotiation begins immediately after the CRLF at the end of | |
361 | the tagged OK response from the server. Once a client issues a | |
362 | STARTTLS command, it MUST NOT issue further commands until a | |
363 | server response is seen and the TLS negotiation is complete. | |
364 | ||
365 | The STARTTLS command is only valid in non-authenticated state. | |
366 | The server remains in non-authenticated state, even if client | |
367 | credentials are supplied during the TLS negotiation. The SASL | |
368 | [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS | |
369 | client credentials are successfully exchanged, but servers | |
370 | supporting the STARTTLS command are not required to support the | |
371 | EXTERNAL mechanism. | |
372 | ||
373 | After the TLS layer is established, the server MUST re-issue an | |
374 | untagged ACAP greeting. This is necessary to protect against | |
375 | man-in-the-middle attacks which alter the capabilities list prior | |
376 | to STARTTLS. The client MUST discard cached capability | |
377 | information and replace it with the information from the new ACAP | |
378 | greeting. The server MAY advertise different capabilities after | |
379 | STARTTLS. | |
380 | ||
381 | The formal syntax for ACAP is amended as follows: | |
382 | ||
383 | command_any =/ "STARTTLS" | |
384 | ||
385 | Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) | |
386 | C: a002 STARTTLS | |
387 | S: a002 OK "Begin TLS negotiation now" | |
388 | <TLS negotiation, further commands are under TLS layer> | |
389 | S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") | |
390 | ||
391 | ||
392 | ||
393 | ||
394 | Newman Standards Track [Page 7] | |
395 | \f | |
396 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
397 | ||
398 | ||
399 | 6. PLAIN SASL mechanism | |
400 | ||
401 | Clear-text passwords are simple, interoperate with almost all | |
402 | existing operating system authentication databases, and are useful | |
403 | for a smooth transition to a more secure password-based | |
404 | authentication mechanism. The drawback is that they are unacceptable | |
405 | for use over an unencrypted network connection. | |
406 | ||
407 | This defines the "PLAIN" SASL mechanism for use with ACAP and other | |
408 | protocols with no clear-text login command. The PLAIN SASL mechanism | |
409 | MUST NOT be advertised or used unless a strong encryption layer (such | |
410 | as the provided by TLS) is active or backwards compatibility dictates | |
411 | otherwise. | |
412 | ||
413 | The mechanism consists of a single message from the client to the | |
414 | server. The client sends the authorization identity (identity to | |
415 | login as), followed by a US-ASCII NUL character, followed by the | |
416 | authentication identity (identity whose password will be used), | |
417 | followed by a US-ASCII NUL character, followed by the clear-text | |
418 | password. The client may leave the authorization identity empty to | |
419 | indicate that it is the same as the authentication identity. | |
420 | ||
421 | The server will verify the authentication identity and password with | |
422 | the system authentication database and verify that the authentication | |
423 | credentials permit the client to login as the authorization identity. | |
424 | If both steps succeed, the user is logged in. | |
425 | ||
426 | The server MAY also use the password to initialize any new | |
427 | authentication database, such as one suitable for CRAM-MD5 | |
428 | [CRAM-MD5]. | |
429 | ||
430 | Non-US-ASCII characters are permitted as long as they are represented | |
431 | in UTF-8 [UTF-8]. Use of non-visible characters or characters which | |
432 | a user may be unable to enter on some keyboards is discouraged. | |
433 | ||
434 | The formal grammar for the client message using Augmented BNF [ABNF] | |
435 | follows. | |
436 | ||
437 | message = [authorize-id] NUL authenticate-id NUL password | |
438 | authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets | |
439 | authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets | |
440 | password = 1*UTF8-SAFE ; MUST accept up to 255 octets | |
441 | NUL = %x00 | |
442 | UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / | |
443 | UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 | |
444 | UTF8-1 = %x80-BF | |
445 | UTF8-2 = %xC0-DF UTF8-1 | |
446 | UTF8-3 = %xE0-EF 2UTF8-1 | |
447 | ||
448 | ||
449 | ||
450 | Newman Standards Track [Page 8] | |
451 | \f | |
452 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
453 | ||
454 | ||
455 | UTF8-4 = %xF0-F7 3UTF8-1 | |
456 | UTF8-5 = %xF8-FB 4UTF8-1 | |
457 | UTF8-6 = %xFC-FD 5UTF8-1 | |
458 | ||
459 | Here is an example of how this might be used to initialize a CRAM-MD5 | |
460 | authentication database for ACAP: | |
461 | ||
462 | Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) | |
463 | C: a001 AUTHENTICATE "CRAM-MD5" | |
464 | S: + "<1896.697170952@postoffice.reston.mci.net>" | |
465 | C: "tim b913a602c7eda7a495b4e6e7334d3890" | |
466 | S: a001 NO (TRANSITION-NEEDED) | |
467 | "Please change your password, or use TLS to login" | |
468 | C: a002 STARTTLS | |
469 | S: a002 OK "Begin TLS negotiation now" | |
470 | <TLS negotiation, further commands are under TLS layer> | |
471 | S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") | |
472 | C: a003 AUTHENTICATE "PLAIN" {21+} | |
473 | C: <NUL>tim<NUL>tanstaaftanstaaf | |
474 | S: a003 OK CRAM-MD5 password initialized | |
475 | ||
476 | Note: In this example, <NUL> represents a single ASCII NUL octet. | |
477 | ||
478 | 7. imaps and pop3s ports | |
479 | ||
480 | Separate "imaps" and "pop3s" ports were registered for use with SSL. | |
481 | Use of these ports is discouraged in favor of the STARTTLS or STLS | |
482 | commands. | |
483 | ||
484 | A number of problems have been observed with separate ports for | |
485 | "secure" variants of protocols. This is an attempt to enumerate some | |
486 | of those problems. | |
487 | ||
488 | - Separate ports lead to a separate URL scheme which intrudes into | |
489 | the user interface in inappropriate ways. For example, many web | |
490 | pages use language like "click here if your browser supports SSL." | |
491 | This is a decision the browser is often more capable of making than | |
492 | the user. | |
493 | ||
494 | - Separate ports imply a model of either "secure" or "not secure." | |
495 | This can be misleading in a number of ways. First, the "secure" | |
496 | port may not in fact be acceptably secure as an export-crippled | |
497 | cipher suite might be in use. This can mislead users into a false | |
498 | sense of security. Second, the normal port might in fact be | |
499 | secured by using a SASL mechanism which includes a security layer. | |
500 | Thus the separate port distinction makes the complex topic of | |
501 | security policy even more confusing. One common result of this | |
502 | confusion is that firewall administrators are often misled into | |
503 | ||
504 | ||
505 | ||
506 | Newman Standards Track [Page 9] | |
507 | \f | |
508 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
509 | ||
510 | ||
511 | permitting the "secure" port and blocking the standard port. This | |
512 | could be a poor choice given the common use of SSL with a 40-bit | |
513 | key encryption layer and plain-text password authentication is less | |
514 | secure than strong SASL mechanisms such as GSSAPI with Kerberos 5. | |
515 | ||
516 | - Use of separate ports for SSL has caused clients to implement only | |
517 | two security policies: use SSL or don't use SSL. The desirable | |
518 | security policy "use TLS when available" would be cumbersome with | |
519 | the separate port model, but is simple with STARTTLS. | |
520 | ||
521 | - Port numbers are a limited resource. While they are not yet in | |
522 | short supply, it is unwise to set a precedent that could double (or | |
523 | worse) the speed of their consumption. | |
524 | ||
525 | ||
526 | 8. IANA Considerations | |
527 | ||
528 | This constitutes registration of the "STARTTLS" and "LOGINDISABLED" | |
529 | IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP]. | |
530 | ||
531 | The registration for the POP3 "STLS" capability follows: | |
532 | ||
533 | CAPA tag: STLS | |
534 | Arguments: none | |
535 | Added commands: STLS | |
536 | Standard commands affected: May enable USER/PASS as a side-effect. | |
537 | CAPA command SHOULD be re-issued after successful completion. | |
538 | Announced states/Valid states: AUTHORIZATION state only. | |
539 | Specification reference: this memo | |
540 | ||
541 | The registration for the ACAP "STARTTLS" capability follows: | |
542 | ||
543 | Capability name: STARTTLS | |
544 | Capability keyword: STARTTLS | |
545 | Capability arguments: none | |
546 | Published Specification(s): this memo | |
547 | Person and email address for further information: | |
548 | see author's address section below | |
549 | ||
550 | The registration for the PLAIN SASL mechanism follows: | |
551 | ||
552 | SASL mechanism name: PLAIN | |
553 | Security Considerations: See section 9 of this memo | |
554 | Published specification: this memo | |
555 | Person & email address to contact for further information: | |
556 | see author's address section below | |
557 | Intended usage: COMMON | |
558 | Author/Change controller: see author's address section below | |
559 | ||
560 | ||
561 | ||
562 | Newman Standards Track [Page 10] | |
563 | \f | |
564 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
565 | ||
566 | ||
567 | 9. Security Considerations | |
568 | ||
569 | TLS only provides protection for data sent over a network connection. | |
570 | Messages transferred over IMAP or POP3 are still available to server | |
571 | administrators and usually subject to eavesdropping, tampering and | |
572 | forgery when transmitted through SMTP or NNTP. TLS is no substitute | |
573 | for an end-to-end message security mechanism using MIME security | |
574 | multiparts [MIME-SEC]. | |
575 | ||
576 | A man-in-the-middle attacker can remove STARTTLS from the capability | |
577 | list or generate a failure response to the STARTTLS command. In | |
578 | order to detect such an attack, clients SHOULD warn the user when | |
579 | session privacy is not active and/or be configurable to refuse to | |
580 | proceed without an acceptable level of security. | |
581 | ||
582 | A man-in-the-middle attacker can always cause a down-negotiation to | |
583 | the weakest authentication mechanism or cipher suite available. For | |
584 | this reason, implementations SHOULD be configurable to refuse weak | |
585 | mechanisms or cipher suites. | |
586 | ||
587 | Any protocol interactions prior to the TLS handshake are performed in | |
588 | the clear and can be modified by a man-in-the-middle attacker. For | |
589 | this reason, clients MUST discard cached information about server | |
590 | capabilities advertised prior to the start of the TLS handshake. | |
591 | ||
592 | Clients are encouraged to clearly indicate when the level of | |
593 | encryption active is known to be vulnerable to attack using modern | |
594 | hardware (such as encryption keys with 56 bits of entropy or less). | |
595 | ||
596 | The LOGINDISABLED IMAP capability (discussed in section 3.2) only | |
597 | reduces the potential for passive attacks, it provides no protection | |
598 | against active attacks. The responsibility remains with the client | |
599 | to avoid sending a password over a vulnerable channel. | |
600 | ||
601 | The PLAIN mechanism relies on the TLS encryption layer for security. | |
602 | When used without TLS, it is vulnerable to a common network | |
603 | eavesdropping attack. Therefore PLAIN MUST NOT be advertised or used | |
604 | unless a suitable TLS encryption layer is active or backwards | |
605 | compatibility dictates otherwise. | |
606 | ||
607 | When the PLAIN mechanism is used, the server gains the ability to | |
608 | impersonate the user to all services with the same password | |
609 | regardless of any encryption provided by TLS or other network privacy | |
610 | mechanisms. While many other authentication mechanisms have similar | |
611 | weaknesses, stronger SASL mechanisms such as Kerberos address this | |
612 | issue. Clients are encouraged to have an operational mode where all | |
613 | mechanisms which are likely to reveal the user's password to the | |
614 | server are disabled. | |
615 | ||
616 | ||
617 | ||
618 | Newman Standards Track [Page 11] | |
619 | \f | |
620 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
621 | ||
622 | ||
623 | The security considerations for TLS apply to STARTTLS and the | |
624 | security considerations for SASL apply to the PLAIN mechanism. | |
625 | Additional security requirements are discussed in section 2. | |
626 | ||
627 | 10. References | |
628 | ||
629 | [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |
630 | Specifications: ABNF", RFC 2234, November 1997. | |
631 | ||
632 | [ACAP] Newman, C. and J. Myers, "ACAP -- Application | |
633 | Configuration Access Protocol", RFC 2244, November 1997. | |
634 | ||
635 | [AUTH] Haller, N. and R. Atkinson, "On Internet Authentication", | |
636 | RFC 1704, October 1994. | |
637 | ||
638 | [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP | |
639 | AUTHorize Extension for Simple Challenge/Response", RFC | |
640 | 2195, September 1997. | |
641 | ||
642 | [IMAP] Crispin, M., "Internet Message Access Protocol - Version | |
643 | 4rev1", RFC 2060, December 1996. | |
644 | ||
645 | [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | |
646 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
647 | ||
648 | [MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed, | |
649 | "Security Multiparts for MIME: Multipart/Signed and | |
650 | Multipart/Encrypted", RFC 1847, October 1995. | |
651 | ||
652 | [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | |
653 | STD 53, RFC 1939, May 1996. | |
654 | ||
655 | [POP3EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension | |
656 | Mechanism", RFC 2449, November 1998. | |
657 | ||
658 | [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, | |
659 | December 1994. | |
660 | ||
661 | [SASL] Myers, J., "Simple Authentication and Security Layer | |
662 | (SASL)", RFC 2222, October 1997. | |
663 | ||
664 | [SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over | |
665 | TLS", RFC 2487, January 1999. | |
666 | ||
667 | [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", | |
668 | RFC 2246, January 1999. | |
669 | ||
670 | ||
671 | ||
672 | ||
673 | ||
674 | Newman Standards Track [Page 12] | |
675 | \f | |
676 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
677 | ||
678 | ||
679 | [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO | |
680 | 10646", RFC 2279, January 1998. | |
681 | ||
682 | ||
683 | 11. Author's Address | |
684 | ||
685 | Chris Newman | |
686 | Innosoft International, Inc. | |
687 | 1050 Lakes Drive | |
688 | West Covina, CA 91790 USA | |
689 | ||
690 | EMail: chris.newman@innosoft.com | |
691 | ||
692 | ||
693 | A. Appendix -- Compliance Checklist | |
694 | ||
695 | An implementation is not compliant if it fails to satisfy one or more | |
696 | of the MUST requirements for the protocols it implements. An | |
697 | implementation that satisfies all the MUST and all the SHOULD | |
698 | requirements for its protocols is said to be "unconditionally | |
699 | compliant"; one that satisfies all the MUST requirements but not all | |
700 | the SHOULD requirements for its protocols is said to be | |
701 | "conditionally compliant". | |
702 | ||
703 | Rules Section | |
704 | ----- ------- | |
705 | Mandatory-to-implement Cipher Suite 2.1 | |
706 | SHOULD have mode where encryption required 2.2 | |
707 | server SHOULD have mode where TLS not required 2.2 | |
708 | MUST be configurable to refuse all clear-text login | |
709 | commands or mechanisms 2.3 | |
710 | server SHOULD be configurable to refuse clear-text | |
711 | login commands on entire server and on per-user basis 2.3 | |
712 | client MUST check server identity 2.4 | |
713 | client MUST use hostname used to open connection 2.4 | |
714 | client MUST NOT use hostname from insecure remote lookup 2.4 | |
715 | client SHOULD support subjectAltName of dNSName type 2.4 | |
716 | client SHOULD ask for confirmation or terminate on fail 2.4 | |
717 | MUST check result of STARTTLS for acceptable privacy 2.5 | |
718 | client MUST NOT issue commands after STARTTLS | |
719 | until server response and negotiation done 3.1,4,5.1 | |
720 | client MUST discard cached information 3.1,4,5.1,9 | |
721 | client SHOULD re-issue CAPABILITY/CAPA command 3.1,4 | |
722 | IMAP server with STARTTLS MUST implement LOGINDISABLED 3.2 | |
723 | IMAP client MUST NOT issue LOGIN if LOGINDISABLED 3.2 | |
724 | POP server MUST implement POP3 extensions 4 | |
725 | ACAP server MUST re-issue ACAP greeting 5.1 | |
726 | ||
727 | ||
728 | ||
729 | ||
730 | Newman Standards Track [Page 13] | |
731 | \f | |
732 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
733 | ||
734 | ||
735 | client SHOULD warn when session privacy not active and/or | |
736 | refuse to proceed without acceptable security level 9 | |
737 | SHOULD be configurable to refuse weak mechanisms or | |
738 | cipher suites 9 | |
739 | ||
740 | The PLAIN mechanism is an optional part of this specification. | |
741 | However if it is implemented the following rules apply: | |
742 | ||
743 | Rules Section | |
744 | ----- ------- | |
745 | MUST NOT use PLAIN unless strong encryption active | |
746 | or backwards compatibility dictates otherwise 6,9 | |
747 | MUST use UTF-8 encoding for characters in PLAIN 6 | |
748 | ||
749 | ||
750 | ||
751 | ||
752 | ||
753 | ||
754 | ||
755 | ||
756 | ||
757 | ||
758 | ||
759 | ||
760 | ||
761 | ||
762 | ||
763 | ||
764 | ||
765 | ||
766 | ||
767 | ||
768 | ||
769 | ||
770 | ||
771 | ||
772 | ||
773 | ||
774 | ||
775 | ||
776 | ||
777 | ||
778 | ||
779 | ||
780 | ||
781 | ||
782 | ||
783 | ||
784 | ||
785 | ||
786 | Newman Standards Track [Page 14] | |
787 | \f | |
788 | RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 | |
789 | ||
790 | ||
791 | Full Copyright Statement | |
792 | ||
793 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
794 | ||
795 | This document and translations of it may be copied and furnished to | |
796 | others, and derivative works that comment on or otherwise explain it | |
797 | or assist in its implementation may be prepared, copied, published | |
798 | and distributed, in whole or in part, without restriction of any | |
799 | kind, provided that the above copyright notice and this paragraph are | |
800 | included on all such copies and derivative works. However, this | |
801 | document itself may not be modified in any way, such as by removing | |
802 | the copyright notice or references to the Internet Society or other | |
803 | Internet organizations, except as needed for the purpose of | |
804 | developing Internet standards in which case the procedures for | |
805 | copyrights defined in the Internet Standards process must be | |
806 | followed, or as required to translate it into languages other than | |
807 | English. | |
808 | ||
809 | The limited permissions granted above are perpetual and will not be | |
810 | revoked by the Internet Society or its successors or assigns. | |
811 | ||
812 | This document and the information contained herein is provided on an | |
813 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
814 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
815 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
816 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
817 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
818 | ||
819 | Acknowledgement | |
820 | ||
821 | Funding for the RFC Editor function is currently provided by the | |
822 | Internet Society. | |
823 | ||
824 | ||
825 | ||
826 | ||
827 | ||
828 | ||
829 | ||
830 | ||
831 | ||
832 | ||
833 | ||
834 | ||
835 | ||
836 | ||
837 | ||
838 | ||
839 | ||
840 | ||
841 | ||
842 | Newman Standards Track [Page 15] | |
843 | \f |