Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-newman-tls-imappop-00.txt < prev next >

Wrap

Text File | 1997-08-28 | 20KB | 509 lines

Network Working Group C. Newman Internet Draft: Protecting IMAP4 and POP3 Connections Innosoft Document: draft-newman-tls-imappop-00.txt August 1997 Protecting IMAP4 and POP3 Connections 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 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Introduction The TLS protocol [TLS] (formerly known as SSL) provides a way to secure a connection from tampering and evesdropping. Obviously, such security is desirable for IMAP [IMAP4] and POP [POP3]. Although advanced authentication mechanisms [IMAP-AUTH, POP-AUTH] can provide this service with less complexity than TLS, TLS is useful in combination with plaintext password logins and other simple mechanisms as it doesn't require a site to upgrade its authentication database. The common practice of using a separate port for a secure version of each protocol has a number of disadvantages in the IMAP [IMAP4] 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. For IMAP, this is even more serious as it would require the definition of a new URL scheme which would require support for TLS in order to gain access. Newman [Page 1] Internet Draft Protecting IMAP4 and POP3 Connections August 1997 This specification defines extensions to IMAP4 and POP3 which activate TLS. It defines a set of server security policy response codes for use with IMAP4, and extends POP3 to permit such response codes. The response codes MAY be used independently of the TLS extension. 0. Open Issues 1. The cipher suite requirement is included to meet the decisions made at the Munich and Danvers IETF meetings. The additional text about exportable ciphers is my invention to hopefully improve interoperability. Comments are welcome. 2. Should I explicitly revoke registration of the IMAP+SSL port? I'm not inclined to do so as this isn't as serious a design flaw as the SMTP+SSL port, and there are already deployed IMAP+SSL implementations. 3. Any security considerations I missed? 1. Conventions Used in this Document The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 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. 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. Newman [Page 2] Internet Draft Protecting IMAP4 and POP3 Connections August 1997 2.1. STARTTLS Command Arguments: none Responses: no specific responses for this command Result: OK - begin TLS negotiation NO - security layer already active 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. The STARTTLS command MAY be used in any state. However, a NO response MAY result if a security layer is already active. Once a client issues a STARTTLS command, it MUST NOT issue further commands until a server response is seen. If STARTTLS is issued 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. Support for the TLS mechanism TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is REQUIRED by all IMAP software implementing this extension. Implementations MUST NOT assume any other cipher suite is present. Unfortunately, it is possible that due to certain government export restrictions some non-compliant versions of this extension could be deployed. Implementations wishing to interoperate with such non-compliant versions MAY offer the TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA mechanism. However, since 40 bit ciphers are known to be vulnerable to attack by current technology, any client which actives a 40 bit cipher MUST NOT indicate to the user that the connection is secure from evesdropping. The formal syntax for IMAP4 is amended as follows: command_any =/ "STARTTLS" Example: C: a001 CAPABILITY S: * CAPABILITY IMAP4rev1 STARTTLS S: a001 OK CAPABILITY completed C: a002 STARTTLS S: a002 OK Begin TLS negotiation now <TLS negotation begins, futher commands sent under TLS layer> C: a003 LOGIN joe password Newman [Page 3] Internet Draft Protecting IMAP4 and POP3 Connections August 1997 S: a003 OK LOGIN completed 3. New IMAP4 response codes This specification defines three new IMAP4 response codes which MAY be used to communicate server security policy to the client. These MAY be implemented independently of the STARTTLS command. ENCRYPT-NEEDED This occurs on a tagged NO response to an AUTHENTICATE or LOGIN command and indicates that the requested authentication mechanism is only permitted underneath a security layer. The client MAY then issue the STARTTLS command and repeat the same AUTHENTICATE or LOGIN command, or try an AUTHENTICATE command with a stronger mechanism. The client SHOULD record the fact that encryption is needed for that user, server and mechanism combination. AUTH-TOO-WEAK This occurs on a tagged NO response to an AUTHENTICATE or LOGIN command and indicates that the mechanism is too weak and is no longer permitted for that user by site policy. This allows a mechanism to be disabled on a per-user rather than a per-server level which is useful if different users have different security requirements or for transitioning from plaintext LOGIN to a more secure mechanism. The client SHOULD record the fact that the user, server and mechanism combination is no longer permitted. TRANSITION-NEEDED This occurs on a tagged NO response to an AUTHENTICATE command. It indicates that the server has an entry for the specified user in a legacy authentication database but does not yet have credentials to offer the requested mechanism. A client which receives this error code MAY do a one-time login using the LOGIN command or another plaintext mechanism (preferably protected by the STARTTLS command) to initialize credentials for the requested mechanism. Newman [Page 4] Internet Draft Protecting IMAP4 and POP3 Connections August 1997 4. POP3 STARTTLS extension The POP3 STARTTLS extension adds the STLS command to POP3 servers. STLS Arguments: none Restrictions: MAY be given in any state, but MAY fail if a security layer is already active. 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. If STLS is issued in authorization state, the server remains in authorization state, even if client credentials are supplied during the TLS negotiation. The AUTH command [POP3-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. Support for the TLS mechanism TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is REQUIRED by all POP3 software implementing this extension. Implementations MUST NOT assume any other cipher suite is present. Unfortunately, it is possible that due to certain government export restrictions some non-compliant versions of this extension could be deployed. Implementations wishing to interoperate with such non-compliant versions MAY offer the TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA mechanism. However, since 40 bit ciphers are known to be vulnerable to attack by current technology, any client which actives a 40 bit cipher MUST NOT indicate to the user that the connection is secure from evesdropping. Possible Responses: +OK -ERR Examples: C: STLS S: +OK Begin TLS negotiation <TLS negotiation begins> Newman [Page 5] Internet Draft Protecting IMAP4 and POP3 Connections August 1997 ... C: STLS S: -ERR Security Layer already active 5. POP3 response code extension POP3 is currently only capable of indicating success or failure to most commands. Unfortunately, clients often need to know more information about the cause of a failure in order to gracefully recover. The security policy response codes defined for IMAP in section 3 are a specific example of this. This specification amends the POP3 standard to permit an optional response code, enclosed in square brackets, at the beginning of the human readable text portion of a "+OK" or "-ERR" response. Clients supporting this extension MAY remove any information enclosed in square brackets prior to displaying human readable text to the user. Immediately following the open square bracket "[" character is a response code which is interpreted in a case-insensitive fashion by the client. The response code is hierarchical, with a "/" separating levels of detail about the error. Clients MUST ignore unknown hierarchical detail about the response code. This is important, as it could be necessary to provide further detail for response codes in the future. For example, ENCRYPT-NEEDED/TLS and ENCRYPT-NEEDED/SSH might indicate a suggestion to use the TLS or SSH protocols respectively for encryption. Examples: C: USER mrose S: -ERR [ENCRYPT-NEEDED] You need to activate encryption before logging in. 5.1. POP3 response codes This specification defines three new POP3 response codes which MAY be used to communicate server security policy to the client. These MAY be implemented independently of the STARTTLS extension. ENCRYPT-NEEDED This occurs on an -ERR response to an AUTH, USER or APOP command and indicates that the requested authentication mechanism is only permitted underneath a security layer. The client MAY then issue the STLS command and repeat the same AUTH, USER or APOP command or try an AUTH command with a Newman [Page 6] Internet Draft Protecting IMAP4 and POP3 Connections August 1997 stronger mechanism. The client SHOULD record the fact that encryption is needed for that user, server and mechanism combination. AUTH-TOO-WEAK This occurs on an -ERR response to an AUTH, USER or APOP command and indicates that the mechanism is too weak and is no longer permitted for that user by site policy. This allows a mechanism to be disabled on a per-user rather than a per-server level which is useful if different users have different security requirements or for transitioning from plaintext USER/PASS to a more secure mechanism. The client SHOULD record the fact that the user, server and mechanism combination is no longer permitted. TRANSITION-NEEDED This occurs on an -ERR response to an AUTH or APOP command. It indicates that the server has an entry for the specified user in a legacy authentication database but does not yet have credentials to offer the requested mechanism. A client which receives this error code MAY do a one-time login using the USER/PASS commands or another plaintext mechanism (preferably protected by the STLS command) to initialize credentials for the requested mechanism. 6. imaps and pop3s ports Use of the registered "imaps" and "pop3s" ports is hereby strongly discouraged and considered non-standard behavior. 7. Security Considerations The mechanisms described in this document only apply to protecting a single connection. Messages are still available to server administrators and usually subject to evesdropping, tampering and forgery when transmitted through SMTP or NNTP. Protecting messages requires an object security mechanism such as PGP MIME [PGP-MIME]. An active attacker for IMAP can remove STARTTLS from the IMAP CAPABILITY list, or cause the POP3 STLS command to fail with a message such as "-ERR Unknown command." In order to detect such an attack, clients SHOULD either warn the user when session protection is not active, or be configurable to refuse to proceed without an acceptable level of security. Newman [Page 7] Internet Draft Protecting IMAP4 and POP3 Connections August 1997 If a client uses a weak mechanism which sends the user name at the same time as the authentication credentials, such as IMAP4's LOGIN command, the ENCRYPT-NEEDED or AUTH-TOO-WEAK error codes will not prevent exposure. For this reason, clients SHOULD record the fact that that user, server and mechanism combination is unacceptable to prevent future exposure or be configurable to try stronger mechanisms or activate encryption first. An active attacker could cause a bogus TRANSITION-NEEDED response to a stronger authentication mechanism. For this reasons, clients SHOULD either activate TLS prior to authentication or get explicit permission from the user prior to using a plaintext mechanism for automated transition. An attacker might probe for users at a site by trying a strong authentication mechanism which could result in TRANSITION-NEEDED for some users. Strong mechanisms can progress partway through negotiation prior to issuing the TRANSITION-NEEDED failure message in order to avoid this problem. An attacker might probe for users using the POP3 USER command to probe for AUTH-TOO-WEAK or ENCRYPT-NEEDED. Server implementations could use these error codes for unknown users to defeat this attack. Delaying the error until after the PASS command is supplied would unnecessarily reveal a user's password and thus would be a far more serious problem than probing for users. An active 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. 8. References [ABNF] Crocker, "Augmented BNF for Syntax Specifications: ABNF", work in progress. [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text Messages", RFC 822, University of Delaware, August 1982. <ftp://ds.internic.net/rfc/rfc822.txt> [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. <ftp://ds.internic.net/rfc/rfc2060.txt> Newman [Page 8] Internet Draft Protecting IMAP4 and POP3 Connections August 1997 [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731, Carnegie-Mellon University, December 1994. <ftp://ds.internic.net/rfc/rfc1731.txt> [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. <ftp://ds.internic.net/rfc/rfc2119.txt> [PGP-MIME] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, The Aerospace Corporation, October 1996. <ftp://ds.internic.net/rfc/rfc2015.txt> [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. <ftp://ds.internic.net/rfc/rfc1939.txt> [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie Mellon, December 1994. <ftp://ds.internic.net/rfc/rfc1734.txt> [SASL] Myers, "Simple Authentication and Security Layer (SASL)", Work in progress. [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in progress. 9. Author's Address Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA Email: chris.newman@innosoft.com Newman [Page 9]