idnits 2.17.1 draft-newman-tls-imappop-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([ACAP], [POP3], [IMAP], [TLS], [SASL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1999) is 9144 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 1704 (ref. 'AUTH') ** Obsolete normative reference: RFC 2060 (ref. 'IMAP') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 1734 (ref. 'POP-AUTH') (Obsoleted by RFC 5034) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2487 (ref. 'SMTPTLS') (Obsoleted by RFC 3207) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: Using TLS with IMAP, POP3 and ACAP Innosoft 4 Document: draft-newman-tls-imappop-09.txt April 1999 6 Using TLS with IMAP, POP3 and ACAP 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This specification defines extensions to IMAP [IMAP], POP [POP3] 33 and ACAP [ACAP] which activate TLS [TLS]. This also defines a 34 simple PLAIN SASL [SASL] mechanism for use underneath strong TLS 35 encryption with ACAP or other protocols lacking a clear-text login 36 command. 38 1. Motivation 40 The TLS protocol (formerly known as SSL) provides a way to secure 41 an application protocol from tampering and eavesdropping. The 42 option of using such security is desirable for IMAP, POP and ACAP 43 due to common connection eavesdropping and hijacking attacks 44 [AUTH]. Although advanced SASL authentication mechanisms can 45 provide a lightweight version of this service, TLS is complimentary 46 to simple authentication-only SASL mechanisms or deployed 47 clear-text password login commands. 49 Many sites have a high investment in authentication infrastructure 50 (e.g., a large database of a one-way-function applied to user 51 passwords), so a privacy layer which is not tightly bound to user 52 authentication can protect against network eavesdropping attacks 53 without requiring a new authentication infrastructure and/or 54 forcing all users to change their password. Recognizing that such 55 sites will desire simple password authentication in combination 56 with TLS encryption, this specification defines the PLAIN SASL 57 mechanism for use with protocols which lack a simple password 58 authentication command such as ACAP and SMTP. (Note there is a 59 separate RFC for the STARTTLS command in SMTP [SMTPTLS].) 61 There is a strong desire in the IETF to eliminate the transmission 62 of clear-text passwords over unencrypted channels. While SASL can 63 be used for this purpose, TLS provides an additional tool with 64 different deployability characteristics. A server supporting both 65 TLS with simple passwords and a challenge/response SASL mechanism 66 is likely to interoperate with a wide variety of clients without 67 resorting to unencrypted clear-text passwords. 69 The STARTTLS command rectifies a number of the problems with using 70 a separate port for a "secure" protocol variant. Some of these are 71 mentioned in section 7. 73 1.1. Conventions Used in this Document 75 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 76 NOT", "MAY", and "OPTIONAL" in this document are to be interpreted 77 as described in "Key words for use in RFCs to Indicate Requirement 78 Levels" [KEYWORDS]. 80 Terms related to authentication are defined in "On Internet 81 Authentication" [AUTH]. 83 Formal syntax is defined using ABNF [ABNF]. 85 In examples, "C:" and "S:" indicate lines sent by the client and 86 server respectively. 88 2. Basic Interoperability and Security Requirements 90 The following requirements apply to all implementations of the 91 STARTTLS extension for IMAP, POP3 and ACAP. 93 2.1. Cipher Suite Requirements 95 Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] 96 cipher suite is REQUIRED. This is important as it assures that any 97 two compliant implementations can be configured to interoperate. 99 All other cipher suites are OPTIONAL. 101 2.2. Privacy Operational Mode Security Requirements 103 Both clients and servers SHOULD have a privacy operational mode 104 which refuses authentication unless successful activation of an 105 encryption layer (such as that provided by TLS) occurs prior to or 106 at the time of authentication and which will terminate the 107 connection if that encryption layer is deactivated. 108 Implementations are encouraged to have flexability with respect to 109 the minimal encryption strength or cipher suites permitted. A 110 minimalist approach to this recommendation would be an operational 111 mode where the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is 112 mandatory prior to permitting authentication. 114 Clients MAY have an operational mode which uses encryption only 115 when it is advertised by the server, but authentication continues 116 regardless. For backwards compatibility, servers SHOULD have an 117 operational mode where only the authentication mechanisms required 118 by the relevant base protocol specification are needed to 119 successfully authenticate. 121 2.3. Clear-Text Password Requirements 123 Clients and servers which implement STARTTLS MUST be configurable 124 to refuse all clear-text login commands or mechanisms (including 125 both standards-track and nonstandard mechanisms) unless an 126 encryption layer of adequate strength is active. Servers which 127 allow unencrypted clear-text logins SHOULD be configurable to 128 refuse clear-text logins both for the entire server, and on a 129 per-user basis. 131 2.4. Server Identity Check 133 During the TLS negotiation, the client MUST check its understanding 134 of the server hostname against the server's identity as presented 135 in the server Certificate message, in order to prevent 136 man-in-the-middle attacks. Matching is performed according to 137 these rules: 139 o The client MUST use the server hostname it used to open the 140 connection as the value to compare against the server name as 141 expressed in the server certificate. The client MUST NOT use 142 any form of the server hostname derived from an insecure remote 143 source (e.g., insecure DNS lookup). CNAME canonicalization is 144 not done. 146 o If a subjectAltName extension of type dNSName is present in the 147 certificate, it SHOULD be used as the source of the server's 148 identity. 150 o Matching is case-insensitive. 152 o A "*" wildcard character MAY be used as the left-most name 153 component in the certificate. For example, *.example.com would 154 match a.example.com, foo.example.com, etc. but would not match 155 example.com. 157 o If the certificate contains multiple names (e.g. more than one 158 dNSName field), then a match with any one of the fields is 159 considered acceptable. 161 If the match fails, the client SHOULD either ask for explicit user 162 confirmation, or terminate the connection and indicate the server's 163 identity is suspect. 165 2.5. TLS Security Policy Check 167 Both the client and server MUST check the result of the STARTTLS 168 command and subsequent TLS negotiation to see whether acceptable 169 authentication or privacy was achieved. Ignoring this step 170 completely invalidates using TLS for security. The decision about 171 whether acceptable authentication or privacy was achieved is made 172 locally, is implementation-dependent, and is beyond the scope of 173 this document. 175 3. IMAP STARTTLS extension 177 When the TLS extension is present in IMAP, "STARTTLS" is listed as 178 a capability in response to the CAPABILITY command. This extension 179 adds a single command, "STARTTLS" to the IMAP protocol which is 180 used to begin a TLS negotiation. 182 3.1. STARTTLS Command 184 Arguments: none 186 Responses: no specific responses for this command 188 Result: OK - begin TLS negotiation 189 BAD - command unknown or arguments invalid 191 A TLS negotiation begins immediately after the CRLF at the end of 192 the tagged OK response from the server. Once a client issues a 193 STARTTLS command, it MUST NOT issue further commands until a 194 server response is seen and the TLS negotiation is complete. 196 The STARTTLS command is only valid in non-authenticated state. 197 The server remains in non-authenticated state, even if client 198 credentials are supplied during the TLS negotiation. The SASL 199 [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS 200 client credentials are successfully exchanged, but servers 201 supporting the STARTTLS command are not required to support the 202 EXTERNAL mechanism. 204 Once TLS has been started, the client MUST discard cached 205 information about server capabilities and SHOULD re-issue the 206 CAPABILITY command. This is necessary to protect against 207 man-in-the-middle attacks which alter the capabilities list prior 208 to STARTTLS. The server MAY advertise different capabilities 209 after STARTTLS. 211 The formal syntax for IMAP is amended as follows: 213 command_any =/ "STARTTLS" 215 Example: C: a001 CAPABILITY 216 S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED 217 S: a001 OK CAPABILITY completed 218 C: a002 STARTTLS 219 S: a002 OK Begin TLS negotiation now 220 221 C: a003 CAPABILITY 222 S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL 223 S: a003 OK CAPABILITY completed 224 C: a004 LOGIN joe password 225 S: a004 OK LOGIN completed 227 3.2. IMAP LOGINDISABLED capability 229 The current IMAP protocol specification (RFC 2060) requires the 230 implementation of the LOGIN command which uses clear-text 231 passwords. Many sites may choose to disable this command unless 232 encryption is active for security reasons. An IMAP server MAY 233 advertise that the LOGIN command is disabled by including the 234 LOGINDISABLED capability in the capability response. Such a server 235 will respond with a tagged "NO" response to any attempt to use the 236 LOGIN command. 238 An IMAP server which implements STARTTLS MUST implement support for 239 the LOGINDISABLED capability on unencrypted connections. 241 An IMAP client which complies with this specification MUST NOT 242 issue the LOGIN command if this capability is present. 244 This capability is useful to prevent clients compliant with this 245 specification from sending an unencrypted password in an 246 environment subject to passive attacks. It has no impact on an 247 environment subject to active attacks as a man-in-the-middle 248 attacker can remove this capability. Therefore this does not 249 relieve clients of the need to follow the privacy mode 250 recommendation in section 2.2. 252 Servers advertising this capability will fail to interoperate with 253 many existing compliant IMAP clients and will be unable to prevent 254 those clients from disclosing the user's password. 256 4. POP3 STARTTLS extension 258 The POP3 STARTTLS extension adds the STLS command to POP3 servers. 259 If this is implemented, the POP3 extension mechanism [POP3EXT] MUST 260 also be implemented to avoid the need for client probing of multiple 261 commands. The capability name "STLS" indicates this command is 262 present and permitted in the current state. 264 STLS 266 Arguments: none 268 Restrictions: 269 Only permitted in AUTHORIZATION state. 271 Discussion: 272 A TLS negotiation begins immediately after the CRLF at the 273 end of the +OK response from the server. A -ERR response 274 MAY result if a security layer is already active. Once a 275 client issues a STLS command, it MUST NOT issue further 276 commands until a server response is seen and the TLS 277 negotiation is complete. 279 The STLS command is only permitted in AUTHORIZATION state 280 and the server remains in AUTHORIZATION state, even if 281 client credentials are supplied during the TLS negotiation. 282 The AUTH command [POP-AUTH] with the EXTERNAL mechanism 283 [SASL] MAY be used to authenticate once TLS client 284 credentials are successfully exchanged, but servers 285 supporting the STLS command are not required to support the 286 EXTERNAL mechanism. 288 Once TLS has been started, the client MUST discard cached 289 information about server capabilities and SHOULD re-issue 290 the CAPA command. This is necessary to protect against 291 man-in-the-middle attacks which alter the capabilities list 292 prior to STLS. The server MAY advertise different 293 capabilities after STLS. 295 Possible Responses: 296 +OK -ERR 298 Examples: 299 C: STLS 300 S: +OK Begin TLS negotiation 301 302 ... 303 C: STLS 304 S: -ERR Command not permitted when TLS active 306 5. ACAP STARTTLS extension 308 When the TLS extension is present in ACAP, "STARTTLS" is listed as 309 a capability in the ACAP greeting. No arguments to this capability 310 are defined at this time. This extension adds a single command, 311 "STARTTLS" to the ACAP protocol which is used to begin a TLS 312 negotiation. 314 5.1. STARTTLS Command 316 Arguments: none 318 Responses: no specific responses for this command 320 Result: OK - begin TLS negotiation 321 BAD - command unknown or arguments invalid 323 A TLS negotiation begins immediately after the CRLF at the end of 324 the tagged OK response from the server. Once a client issues a 325 STARTTLS command, it MUST NOT issue further commands until a 326 server response is seen and the TLS negotiation is complete. 328 The STARTTLS command is only valid in non-authenticated state. 329 The server remains in non-authenticated state, even if client 330 credentials are supplied during the TLS negotiation. The SASL 331 [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS 332 client credentials are successfully exchanged, but servers 333 supporting the STARTTLS command are not required to support the 334 EXTERNAL mechanism. 336 After the TLS layer is established, the server MUST re-issue an 337 untagged ACAP greeting. This is necessary to protect against 338 man-in-the-middle attacks which alter the capabilities list prior 339 to STARTTLS. The client MUST discard cached capability 340 information and replace it with the information from the new ACAP 341 greeting. The server MAY advertise different capabilities after 342 STARTTLS. 344 The formal syntax for ACAP is amended as follows: 346 command_any =/ "STARTTLS" 348 Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) 349 C: a002 STARTTLS 350 S: a002 OK "Begin TLS negotiation now" 351 352 S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") 354 6. PLAIN SASL mechanism 356 Clear-text passwords are simple, interoperate with almost all 357 existing operating system authentication databases, and are useful 358 for a smooth transition to a more secure password-based 359 authentication mechanism. The drawback is that they are 360 unacceptable for use over an unencrypted network connection. 362 This defines the "PLAIN" SASL mechanism for use with ACAP and other 363 protocols with no clear-text login command. The PLAIN SASL 364 mechanism MUST NOT be advertised or used unless a strong encryption 365 layer (such as the provided by TLS) is active or backwards 366 compatibility dictates otherwise. 368 The mechanism consists of a single message from the client to the 369 server. The client sends the authorization identity (identity to 370 login as), followed by a US-ASCII NUL character, followed by the 371 authentication identity (identity whose password will be used), 372 followed by a US-ASCII NUL character, followed by the clear-text 373 password. The client may leave the authorization identity empty to 374 indicate that it is the same as the authentication identity. 376 The server will verify the authentication identity and password 377 with the system authentication database and verify that the 378 authentication credentials permit the client to login as the 379 authorization identity. If both steps succeed, the user is logged 380 in. 382 The server MAY also use the password to initialize any new 383 authentication database, such as one suitable for CRAM-MD5 384 [CRAM-MD5]. 386 Non-US-ASCII characters are permitted as long as they are 387 represented in UTF-8 [UTF-8]. Use of non-visible characters or 388 characters which a user may be unable to enter on some keyboards is 389 discouraged. 391 The formal grammar for the client message using Augmented BNF 392 [ABNF] follows. 394 message = [authorize-id] NUL authenticate-id NUL password 395 authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets 396 authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets 397 password = 1*UTF8-SAFE ; MUST accept up to 255 octets 398 NUL = %x00 399 UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / 400 UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 401 UTF8-1 = %x80-BF 402 UTF8-2 = %xC0-DF UTF8-1 403 UTF8-3 = %xE0-EF 2UTF8-1 404 UTF8-4 = %xF0-F7 3UTF8-1 405 UTF8-5 = %xF8-FB 4UTF8-1 406 UTF8-6 = %xFC-FD 5UTF8-1 408 Here is an example of how this might be used to initialize a 409 CRAM-MD5 authentication database for ACAP: 411 Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) 412 C: a001 AUTHENTICATE "CRAM-MD5" 413 S: + "<1896.697170952@postoffice.reston.mci.net>" 414 C: "tim b913a602c7eda7a495b4e6e7334d3890" 415 S: a001 NO (TRANSITION-NEEDED) 416 "Please change your password, or use TLS to login" 417 C: a002 STARTTLS 418 S: a002 OK "Begin TLS negotiation now" 419 420 S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") 421 C: a003 AUTHENTICATE "PLAIN" {21+} 422 C: timtanstaaftanstaaf 423 S: a003 OK CRAM-MD5 password initialized 425 Note: In this example, represents a single ASCII NUL octet. 427 7. imaps and pop3s ports 429 Separate "imaps" and "pop3s" ports were registered for use with 430 SSL. Use of these ports is discouraged in favor of the STARTTLS or 431 STLS commands. 433 A number of problems have been observed with separate ports for 434 "secure" variants of protocols. This is an attempt to enumerate 435 some of those problems. 437 o Separate ports lead to a separate URL scheme which intrudes into 438 the user interface in inappropriate ways. For example, many web 439 pages use language like "click here if your browser supports 440 SSL." This is a decision the browser is often more capable of 441 making than the user. 443 o Separate ports imply a model of either "secure" or "not secure." 444 This can be misleading in a number of ways. First, the "secure" 445 port may not in fact be acceptably secure as an export-crippled 446 cipher suite might be in use. This can mislead users into a 447 false sense of security. Second, the normal port might in fact 448 be secured by using a SASL mechanism which includes a security 449 layer. Thus the separate port distinction makes the complex 450 topic of security policy even more confusing. One common result 451 of this confusion is that firewall administrators are often 452 misled into permitting the "secure" port and blocking the 453 standard port. This could be a poor choice given the common use 454 of SSL with a 40-bit key encryption layer and plain-text 455 password authentication is less secure than strong SASL 456 mechanisms such as GSSAPI with Kerberos 5. 458 o Use of separate ports for SSL has caused clients to implement 459 only two security policies: use SSL or don't use SSL. The 460 desirable security policy "use TLS when available" would be 461 cumbersome with the separate port model, but is simple with 462 STARTTLS. 464 o Port numbers are a limited resource. While they are not yet in 465 short supply, it is unwise to set a precedent that could double 466 (or worse) the speed of their consumption. 468 8. IANA Considerations 470 This constitutes registration of the "STARTTLS" and "LOGINDISABLED" 471 IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP]. 473 The registration for the POP3 "STLS" capability follows: 475 CAPA tag: STLS 476 Arguments: none 477 Added commands: STLS 478 Standard commands affected: May enable USER/PASS as a side-effect. 479 CAPA command SHOULD be re-issued after successful completion. 480 Announced states/Valid states: AUTHORIZATION state only. 481 Specification reference: this memo 482 The registration for the ACAP "STARTTLS" capability follows: 484 Capability name: STARTTLS 485 Capability keyword: STARTTLS 486 Capability arguments: none 487 Published Specification(s): this memo 488 Person and email address for further information: 489 see author's address section below 491 The registration for the PLAIN SASL mechanism follows: 493 SASL mechanism name: PLAIN 494 Security Considerations: See section 9 of this memo 495 Published specification: this memo 496 Person & email address to contact for further information: 497 see author's address section below 498 Intended usage: COMMON 499 Author/Change controller: see author's address section below 501 9. Security Considerations 503 TLS only provides protection for data sent over a network 504 connection. Messages transferred over IMAP or POP3 are still 505 available to server administrators and usually subject to 506 eavesdropping, tampering and forgery when transmitted through SMTP 507 or NNTP. TLS is no substitute for an end-to-end message security 508 mechanism using MIME security multiparts [MIME-SEC]. 510 A man-in-the-middle attacker can remove STARTTLS from the 511 capability list or generate a failure response to the STARTTLS 512 command. In order to detect such an attack, clients SHOULD warn 513 the user when session privacy is not active and/or be configurable 514 to refuse to proceed without an acceptable level of security. 516 A man-in-the-middle attacker can always cause a down-negotiation to 517 the weakest authentication mechanism or cipher suite available. 518 For this reason, implementations SHOULD be configurable to refuse 519 weak mechanisms or cipher suites. 521 Any protocol interactions prior to the TLS handshake are performed 522 in the clear and can be modified by a man-in-the-middle attacker. 523 For this reason, clients MUST discard cached information about 524 server capabilities advertised prior to the start of the TLS 525 handshake. 527 Clients are encouraged to clearly indicate when the level of 528 encryption active is known to be vulnerable to attack using modern 529 hardware (such as encryption keys with 56 bits of entropy or less). 531 The LOGINDISABLED IMAP capability (discussed in section 3.2) only 532 reduces the potential for passive attacks, it provides no 533 protection against active attacks. The responsibility remains with 534 the client to avoid sending a password over a vulnerable channel. 536 The PLAIN mechanism relies on the TLS encryption layer for 537 security. When used without TLS, it is vulnerable to a common 538 network eavesdropping attack. Therefore PLAIN MUST NOT be 539 advertised or used unless a suitable TLS encryption layer is active 540 or backwards compatibility dictates otherwise. 542 When the PLAIN mechanism is used, the server gains the ability to 543 impersonate the user to all services with the same password 544 regardless of any encryption provided by TLS or other network 545 privacy mechanisms. While many other authentication mechanisms 546 have similar weaknesses, stronger SASL mechanisms such as Kerberos 547 address this issue. Clients are encouraged to have an operational 548 mode where all mechanisms which are likely to reveal the user's 549 password to the server are disabled. 551 The security considerations for TLS apply to STARTTLS and the 552 security considerations for SASL apply to the PLAIN mechanism. 553 Additional security requirements are discussed in section 2. 555 10. References 557 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 558 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 559 November 1997. 561 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 562 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 564 [AUTH] Haller, N., Atkinson, R., "On Internet Authentication", RFC 565 1704, Bell Communications Research, October 1994. 567 [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension 568 for Simple Challenge/Response", RFC 2195, MCI, September 1997. 570 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 571 4rev1", RFC 2060, University of Washington, December 1996. 573 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 574 Requirement Levels", RFC 2119, Harvard University, March 1997. 576 [MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for 577 MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted 578 Information Systems, CyberCash, Innosoft International, October 579 1995. 581 [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 582 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 584 [POP3EXT] Gellens, R., Newman, C., Lundblade, L., "POP3 Extension 585 Mechanism", RFC 2449, November 1998. 587 [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, 588 Carnegie Mellon, December 1994. 590 [SASL] Myers, J., "Simple Authentication and Security Layer 591 (SASL)", RFC 2222, Netscape Communications, October 1997. 593 [SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over 594 TLS", RFC 2487, Internet Mail Consortium, January 1999. 596 [TLS] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 597 2246, Certicom, January 1999. 599 [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", 600 RFC 2279, Alis Technologies, January 1998. 602 11. Author's Address 604 Chris Newman 605 Innosoft International, Inc. 606 1050 Lakes Drive 607 West Covina, CA 91790 USA 609 Email: chris.newman@innosoft.com 611 A. Appendix -- Compliance Checklist 613 An implementation is not compliant if it fails to satisfy one or 614 more of the MUST requirements for the protocols it implements. An 615 implementation that satisfies all the MUST and all the SHOULD 616 requirements for its protocols is said to be "unconditionally 617 compliant"; one that satisfies all the MUST requirements but not 618 all the SHOULD requirements for its protocols is said to be 619 "conditionally compliant". 621 Rules Section 622 ----- ------- 623 Mandatory-to-implement Cipher Suite 2.1 624 SHOULD have mode where encryption required 2.2 625 server SHOULD have mode where TLS not required 2.2 626 MUST be configurable to refuse all clear-text login 627 commands or mechanisms 2.3 628 server SHOULD be configurable to refuse clear-text 629 login commands on entire server and on per-user basis 2.3 630 client MUST check server identity 2.4 631 client MUST use hostname used to open connection 2.4 632 client MUST NOT use hostname from insecure remote lookup 2.4 633 client SHOULD support subjectAltName of dNSName type 2.4 634 client SHOULD ask for confirmation or terminate on fail 2.4 635 MUST check result of STARTTLS for acceptable privacy 2.5 636 client MUST NOT issue commands after STARTTLS 637 until server response and negotiation done 3.1,4,5.1 638 client MUST discard cached information 3.1,4,5.1,9 639 client SHOULD re-issue CAPABILITY/CAPA command 3.1,4 640 IMAP server with STARTTLS MUST implement LOGINDISABLED 3.2 641 IMAP client MUST NOT issue LOGIN if LOGINDISABLED 3.2 642 POP server MUST implement POP3 extensions 4 643 ACAP server MUST re-issue ACAP greeting 5.1 644 client SHOULD warn when session privacy not active and/or 645 refuse to proceed without acceptable security level 9 646 SHOULD be configurable to refuse weak mechanisms or 647 cipher suites 9 649 The PLAIN mechanism is an optional part of this specification. 650 However if it is implemented the following rules apply: 652 Rules Section 653 ----- ------- 654 MUST NOT use PLAIN unless strong encryption active 655 or backwards compatibility dictates otherwise 6,9 656 MUST use UTF-8 encoding for characters in PLAIN 6