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