Network Working Group C. Newman Internet Draft: Using TLS with IMAP4, POP3 and ACAP Innosoft Document: draft-newman-tls-imappop-06.txt December 1998 Updates: RFC 1939, 2060, 2244 Using TLS with IMAP4, POP3 and ACAP Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This specification defines extensions to IMAP [IMAP4], POP [POP3] and ACAP [ACAP] which activate TLS [TLS]. This also defines a simple PLAIN SASL [SASL] mechanism for use underneath strong TLS encryption with ACAP or other protocols lacking a clear-text login command. 1. Motivation The TLS protocol [TLS] (formerly known as SSL) provides a way to secure an application protocol from tampering and eavesdropping. Obviously, the option of using such security is desirable for IMAP [IMAP4], POP [POP3] and ACAP [ACAP]. Although advanced SASL [SASL] authentication mechanisms can provide a lightweight version of this service, TLS is a full service security layer and is complimentary to simple authentication-only SASL mechanisms or clear-text password login commands. Newman [Page 1] Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998 Many sites have a high investment in authentication infrastructure (e.g., a large database of a one-way-function applied to user passwords), so a privacy layer which is not tightly bound to user authentication can protect against network eavesdropping attacks without requiring a new authentication infrastructure and/or forcing all users to change their password. Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. There is a strong desire in the IETF to eliminate the transmission of clear-text passwords over unencrypted channels. While SASL can be used for this purpose, TLS provides an additional tool with different deployability characteristics. A server supporting both TLS with simple passwords and a challenge/response SASL mechanism is likely to interoperate with a wide variety of clients without resorting to unencrypted clear-text passwords. The STARTTLS command is superior to the use of a separate port for TLS, as it simplifies implementation of a client security policy of "use best security available" in addition to the traditional "never use TLS" and "always use TLS" policies that are common with the separate port model. Further discussion on this topic is in section 7. 1.1. Conventions Used in this Document The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. Formal syntax is defined using ABNF [ABNF]. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 2. Basic Interoperability and Security Requirements The following requirements apply to all implementations of the STARTTLS extension for IMAP4, POP3 and ACAP. 2.1. Cipher Suite Requirements Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is REQUIRED. This is important as it assures that any two compliant implementations can be configured to interoperate. Newman [Page 2] Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998 All other cipher suites are OPTIONAL. 2.2. TLS Operational Mode Security Requirements Both clients and servers SHOULD have an operational mode where use of TLS encryption is required to login. Clients MAY have an operational mode where TLS is used only when advertised by the server, but login occurs regardless. For backwards compatibility, servers SHOULD have an operational mode which permits clients to login when TLS is not used. 2.3. Clear-Text Password Requirements A server which implements both STARTTLS and a clear-text password authentication mechanism (including but not limited to the IMAP4 LOGIN command, POP3 PASS command and the PLAIN mechanism in section 6) MUST have an operational mode where all clear-text login commands and mechanisms are disabled unless TLS encryption is active. Furthermore, a server which implements both STARTTLS and a clear-text password mechanism which is not documented in a standards track RFC MUST NOT permit use of that mechanism unless suitable TLS encryption is active. 2.4. Server Identity Check During the TLS negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules: o The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS reverse lookup). o If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity. o Matching is case-insensitive. o A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match Newman [Page 3] Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998 example.com. o If the certificate contains multiple names (e.g. more than one dNSName field), then a match with any one of the fields is considered acceptable. If the match fails, the client SHOULD either ask for explicit user confirmation, or terminate the connection and indicate the server's identity is suspect. 2.5. TLS Security Policy Check Both the client and server MUST check the result of the STARTTLS command and subsequent TLS negotiation to see whether acceptable authentication or privacy was achieved. Ignoring this step completely invalidates using TLS for security. The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependant, and is beyond the scope of this document. 3. IMAP4 STARTTLS extension When the TLS extension is present in IMAP4, "STARTTLS" is listed as a capability in response to the CAPABILITY command. This extension adds a single command, "STARTTLS" to the IMAP4 protocol which is used to begin a TLS negotiation. 3.1. STARTTLS Command Arguments: none Responses: no specific responses for this command Result: OK - begin TLS negotiation BAD - command unknown or arguments invalid A TLS negotiation begins immediately after the CRLF at the end of the tagged OK response from the server. Once a client issues a STARTTLS command, it MUST NOT issue further commands until a server response is seen and the TLS negotiation is complete. The STARTTLS command is only valid in non-authenticated state. The server remains in non-authenticated state, even if client credentials are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS client credentials are successfully exchanged, but servers supporting the STARTTLS command are not required to support the EXTERNAL mechanism. Newman [Page 4] Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998 Once TLS has been started, the client SHOULD discard cached information about server capabilities and re-issue the CAPABILITY command. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS. The formal syntax for IMAP4 is amended as follows: command_any =/ "STARTTLS" Example: C: a001 CAPABILITY S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED S: a001 OK CAPABILITY completed C: a002 STARTTLS S: a002 OK Begin TLS negotiation now C: a003 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL S: a003 OK CAPABILITY completed C: a004 LOGIN joe password S: a004 OK LOGIN completed 3.2. IMAP4 LOGINDISABLED capability The IMAP4 protocol specification requires the implementation of the LOGIN command which uses clear-text passwords. Many sites will choose to disable this command without encryption for all users as STARTTLS support or stronger SASL mechanisms become available in IMAP clients. The IMAP4 server MAY advertise that the LOGIN command is disabled by including the LOGINDISABLED capability in the capability response. An IMAP4 client MUST NOT issue the LOGIN command if this capability is present. This capability does not remove the need for clients to have an explicit "don't use clear-text passwords" configuration option or the equivalent, as a man-in-the-middle attack could remove this capability from the list of advertised capabilities. 4. POP3 STARTTLS extension The POP3 STARTTLS extension adds the STLS command to POP3 servers. If this is implemented, the POP3 extension mechanism [POP3EXT] MUST also be implemented to avoid the need for client probing of multiple commands. The capability name "STLS" indicates this command is present. Newman [Page 5] Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998 STLS Arguments: none Restrictions: Only permitted in AUTHORIZATION state. Discussion: A TLS negotiation begins immediately after the CRLF at the end of the +OK response from the server. A -ERR response MAY result if a security layer is already active. Once a client issues a STLS command, it MUST NOT issue further commands until a server response is seen and the TLS negotiation is complete. The STLS command is only permitted in AUTHORIZATION state and the server remains in AUTHORIZATION state, even if client credentials are supplied during the TLS negotiation. The AUTH command [POP-AUTH] with the EXTERNAL mechanism [SASL] MAY be used to authenticate once TLS client credentials are successfully exchanged, but servers supporting the STLS command are not required to support the EXTERNAL mechanism. Once TLS has been started, the client SHOULD discard cached information about server capabilities and re-issue the CAPA command. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STLS. The server MAY advertise different capabilities after STLS. Possible Responses: +OK -ERR Examples: C: STLS S: +OK Begin TLS negotiation ... C: STLS S: -ERR Command not permitted when TLS active 5. ACAP STARTTLS extension When the TLS extension is present in ACAP, "STARTTLS" is listed as a capability in the ACAP greeting. No arguments to this capability are defined at this time. This extension adds a single command, "STARTTLS" to the ACAP protocol which is used to begin a TLS Newman [Page 6] Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998 negotiation. 5.1. STARTTLS Command Arguments: none Responses: no specific responses for this command Result: OK - begin TLS negotiation BAD - command unknown or arguments invalid A TLS negotiation begins immediately after the CRLF at the end of the tagged OK response from the server. Once a client issues a STARTTLS command, it MUST NOT issue further commands until a server response is seen and the TLS negotiation is complete. The STARTTLS command is only valid in non-authenticated state. The server remains in non-authenticated state, even if client credentials are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS client credentials are successfully exchanged, but servers supporting the STARTTLS command are not required to support the EXTERNAL mechanism. After the TLS layer is established, the server MUST re-issue an untagged ACAP greeting. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STARTTLS. The client SHOULD discard cached capability information and replace it with the information from the new ACAP greeting. The server MAY advertise different capabilities after STARTTLS. The formal syntax for ACAP is amended as follows: command_any =/ "STARTTLS" Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) C: a002 STARTTLS S: a002 OK "Begin TLS negotiation now" S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") 6. PLAIN SASL mechanism Clear-text passwords are simple, interoperate with almost all existing operating system authentication databases, and are useful for a smooth transition to a more secure password-based authentication mechanism. The drawback is that they are Newman [Page 7] Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998 unacceptable for use over an unencrypted network connection. This defines the "PLAIN" SASL mechanism for use with ACAP and other protocols with no clear-text login command. The PLAIN SASL mechanism MUST NOT be used unless strong TLS encryption or an equivalent strong encryption layer is also in use. In particular, if a strong encryption layer is not currently in use in the session, a client MUST NOT attempt to authenticate via the PLAIN SASL mechanism. The mechanism consists of a single message from the client to the server. The client sends the authorization identity (identity to login as), followed by a US-ASCII NUL character, followed by the authentication identity (identity whose password will be used), followed by a US-ASCII NUL character, followed by the clear-text password. The client may leave the authorization identity empty to indicate that it is the same as the authentication identity. The server will verify the authentication identity and password with the system authentication database and verify that the authentication credentials permit the client to login as the authorization identity. If both steps succeed, the user is logged in. The server MAY also use the password to initialize any new authentication database, such as one suitable for CRAM-MD5 [CRAM-MD5]. Non-US-ASCII characters are permitted as long as they are represented in UTF-8 [UTF-8]. Use of non-visible characters or characters which a user may be unable to enter on some keyboards is discouraged. Clients are encouraged to support pure-binary passwords as they may be safe from dictionary attacks. However, if the client offers a character-based interface for password entry it MUST use UTF-8 encoding for the characters. The formal grammar for the client message using Augmented BNF [ABNF] follows. message = [authorize-id] NUL authenticate-id NUL password authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets password = *NZ-OCTET ; MUST accept up to 255 octets NUL = %x00 NZ-OCTET = %x01-FF ; all non-NUL octet values Newman [Page 8] Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998 UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 UTF8-1 = %x80-BF UTF8-2 = %xC0-DF UTF8-1 UTF8-3 = %xE0-EF 2UTF8-1 UTF8-4 = %xF0-F7 3UTF8-1 UTF8-5 = %xF8-FB 4UTF8-1 UTF8-6 = %xFC-FD 5UTF8-1 Here is an example of how this might be used to initialize a CRAM-MD5 authentication database for ACAP: Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) C: a001 AUTHENTICATE "CRAM-MD5" S: + "<1896.697170952@postoffice.reston.mci.net>" C: "tim b913a602c7eda7a495b4e6e7334d3890" S: a001 NO (TRANSITION-NEEDED) "Please change your password, or use TLS to login" C: a002 STARTTLS S: a002 OK "Begin TLS negotiation now" S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") C: a003 AUTHENTICATE "PLAIN" {21+} C: timtanstaaftanstaaf S: a003 OK CRAM-MD5 password initialized Note: In this example, represents a single ASCII NUL octet. Here is an example session where a client erroneously attempts to use PLAIN prior to starting TLS: Example: S: * ACAP (SASL "CRAM-MD5" "PLAIN") (STARTTLS) C: a001 AUTHENTICATE "PLAIN" {21} S: a001 NO (ENCRYPT-NEEDED) "Can't use PLAIN without encryption" 7. imaps and pop3s ports The common practice of using a separate port for a "secure" version of each protocol has a number of disadvantages in the IMAP [IMAP4], ACAP [ACAP] and POP [POP3] environment. Rather than using the best security available, it means that clients have to be explicitly configured to use the separate secure port or suffer the performance loss of probing for active ports. Furthermore this is even more serious as it would require a new URL scheme which could only be resolved by TLS-enabled clients. Separate "imaps" and "pop3s" ports were registered for use with Newman [Page 9] Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998 TLS. Use of these ports is discouraged in favor of the STARTTLS or STLS command. One of the arguments used in favor of the separate port technique is that it simplifies configuration of firewalls which filter by IP port. However, a quality server implementation running on the standard port can be configured to require use of the STARTTLS command or a suitably strong SASL mechanism for non-local connections. This provides superior functionality as the client need not be re-configured for use outside the firewall and faster challenge/response SASL mechanisms may be acceptable to many sites for non-local connections. 8. Registration This document constitutes registration of the "STARTTLS" and "LOGINDISABLED" IMAP4 capabilities as required by section 7.2.1 of RFC 2060 [IMAP4]. This document defines the "STLS" POP3 capability as follows: CAPA tag: STLS Arguments: none Added commands: STLS Standard commands affected: May enable USER/PASS as a side-effect. CAPA command should be re-issued after successful completion. Announced states/Valid states: AUTHORIZATION state only. Specification reference: this memo This document defines the "STARTTLS" ACAP capability as follows: Capability name: STARTTLS Capability keyword: STARTTLS Capability arguments: none Published Specification(s): this memo Person and email address for further information: see author's address section below This document defines the "PLAIN" SASL mechanism as follows: SASL mechanism name: PLAIN Security Considerations: See section 9 of this memo Published specification: this memo Person & email address to contact for further information: see author's address section below Intended usage: COMMON Author/Change controller: see author's address section below Newman [Page 10] Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998 9. Security Considerations TLS only provides protection for data sent over a network connection. Messages transferred over IMAP or POP3 are still available to server administrators and usually subject to eavesdropping, tampering and forgery when transmitted through SMTP or NNTP. TLS is no substitute for an end-to-end message security mechanism using MIME security multiparts [MIME-SEC]. A man-in-the-middle attacker can remove STARTTLS from the capability list. In order to detect such an attack, clients SHOULD either warn the user when session privacy is not active, or be configurable to refuse to proceed without an acceptable level of security. A man-in-the-middle attacker can always cause a down-negotiation to the weakest authentication mechanism or cipher suite available. For this reason, implementations need to be configurable to refuse weak mechanisms or cipher suites. Any protocol interactions prior to the TLS handshake are performed in the clear and can be modified by a man-in-the-middle attacker. For this reason, clients SHOULD discard cached information about server capabilities advertised prior to the start of the TLS handshake. Clients are encouraged to clearly distinguish between a level of encryption known to be vulnerable to a reasonable attack using modern hardware (such as encryption with a 40-bit key) and one which is believed to be safe from such an attack. When the PLAIN mechanism (or the IMAP LOGIN or POP3 PASS command) is used, the server gains the ability to impersonate the user to all services with the same password regardless of any encryption provided by TLS or other network privacy mechanisms. Stronger SASL authentication mechanisms such as Kerberos address this issue. Use of clear-text login mechanisms (e.g., the IMAP LOGIN command, POP3 PASS command or the PLAIN mechanism) without a suitable encryption layer, such as that provided by TLS, expose the user's password to a common network eavesdropping attack. Therefore, the PLAIN mechanism MUST NOT be used unless a suitable encryption layer, such as that provided by TLS, is in use. In addition, this is the primary motivation for the clear-text password requirements in section 2.3. Additional security requirements are discussed in section 2. Newman [Page 11] Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998 10. References [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, November 1997. [ACAP] Newman, Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, Innosoft, Netscape, November 1997. [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, MCI, September 1997. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731, Carnegie-Mellon University, December 1994. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted Information Systems, CyberCash, Innosoft International, October 1995. [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. [POP3EXT] Gellens, R., Newman, C., Lundblade, L., "POP3 Extension Mechanism", RFC 2449, November 1998. [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, Carnegie Mellon, December 1994. [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, Netscape Communications, October 1997. [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in progress. [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", RFC 2279, Alis Technologies, January 1998. 11. Author's Address Chris Newman Innosoft International, Inc. Newman [Page 12] Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998 1050 Lakes Drive West Covina, CA 91790 USA Email: chris.newman@innosoft.com A. Appendix -- Non-Compliant Use of PLAIN RFC 2316 states that "no protocol that relies on passwords sent over unencrypted channels is acceptable." Implementations of the PLAIN mechanism which don't require use of encryption have been released by multiple vendors. Although such use is not compliant with this specification, it is mentioned here so that it can be considered when performing a security analysis of a site or interpreting security warnings. Some implementations have invented undocumented mechanisms to provide unencrypted password authentication. This author believes it is preferable to abuse the PLAIN mechanism rather than using an undocumented channel for unencrypted passwords. This is an additional motivation behind the clear-text password requirements in section 2.3. B. Appendix -- Compliance Checklist An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant". Rules Section ----- ------- Mandatory-to-implement Cipher Suite 2.1 SHOULD have mode where TLS required 2.2 server SHOULD have mode where TLS not required 2.2 MUST have mode where unencrypted password not permitted 2.3 MUST NOT permit non-standard unencrypted password use 2.3 client MUST check server identity 2.4 client MUST use hostname used to open connection 2.4 client MUST NOT use hostname from insecure remote lookup 2.4 client SHOULD support subjectAltName of dNSName type 2.4 client SHOULD ask for confirmation or terminate on fail 2.4 MUST check result of STARTTLS for acceptable privacy 2.5 client MUST NOT issue commands after STARTTLS until server response and negotiation done 3.1,4,5.1 client SHOULD discard cached information 3.1,4,5.1,9 Newman [Page 13] Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998 client SHOULD re-issue CAPABILITY/CAPA command 3.1,4 IMAP client MUST NOT issue LOGIN if LOGINDISABLED 3.2 POP server MUST implement POP3 extensions 4 ACAP server MUST re-issue ACAP greeting 5.1 client SHOULD warn when session privacy not active or refuse to proceed without acceptable security level 9 The PLAIN mechanism is an optional part of this specification. However if it is implemented the following rules apply: Rules Section ----- ------- MUST NOT use PLAIN unless TLS encryption active 6,9 MUST use UTF-8 encoding for characters in PLAIN 6 Newman [Page 14]