rfc2595.txt - rohrpost - A commandline mail client to change the world as we see it.
(HTM) git clone git://r-36.net/rohrpost
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) README
(DIR) LICENSE
---
rfc2595.txt (32440B)
---
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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