INTERNET-DRAFT A. Melnikov Intended Status: Standards Track Isode Limited Updates: 1939, 2595 (if approved) M. Yevstifeyev Expires: November 16, 2011 May 15, 2011 POP3 over TLS (POP3S) <draft-melnikov-pop3-over-tls-00> Abstract This document specifies the POP3 over TLS protocol (POP3S), that is designed to secure the POP3 transaction by establishing TLS layer connection directly before POP3 transaction. It updates RFC 1939 and RFC 2595. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Melnikov & Yevstifeyev Expires November 16, 2011 [Page 1]
INTERNET DRAFT POP3 over TLS May 15, 2011 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. POP3 over TLS Protocol . . . . . . . . . . . . . . . . . . . . 3 2.1. Connection Establishment . . . . . . . . . . . . . . . . . 3 2.2. Data Exchange . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Connection Closure . . . . . . . . . . . . . . . . . . . . 4 2.4. Default Port . . . . . . . . . . . . . . . . . . . . . . . 4 2.5. POP3S Disadvantages . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . . 5 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Post Office Protocol, Version 3 (POP3), that is defined in RFC 1939 [RFC1939], is an application-layer protocol used by local e-mail clients to retrieve e-mail from a remote server over a simple TCP/IP connection. It supports simple download-and-delete requirements for access to remote mailboxes (also called a maildrop). Initially, POP3 was intended to be used "in the clear". But since it is often employed to transfer sensitive information, there is a need to secure POP3 transaction; actually, the only protocol used for this purpose is Transport Layer Security (TLS) [RFC5246] (and its deprecated predecessor Secure Sockets Layer (SSL) [I.D. draft- mavrogiannopoulos-ssl-version3]). Historically, two ways of securing the POP3 connection have been deployed (like 2 ways of securing HTTP [RFC2616]; see below). The first includes establishing TLS layer connection during the POP3 transaction (also known as upgrading to TLS). It is discussed in details in RFC 2595 [RFC2595]. The other one involves establishing TLS connection directly before establishing POP3 transaction. Unlike the first one, this way (called "POP3S" throughout this document) has never been given an official specification. (In the case with HTTP Melnikov & Yevstifeyev Expires November 16, 2011 [Page 2]
INTERNET DRAFT POP3 over TLS May 15, 2011 the first way is specified in RFC 2817 [RFC2817]; the second one - in RFC 2818 [RFC2818].) This memo is to remove this uncertainty; it specifies the POP3S protocol in details. This document updates RFC 1939 [RFC1939]. RFC 2595 [RFC2595] is also updated by it (see Section 2.5 for justification). This memo also updates the registration of the TCP well-known port 995, used with POP3S. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. POP3 over TLS Protocol This section contains the technical definition of POP3 over TLS protocol (POP3S). 2.1. Connection Establishment Establishing POP3S connection, the user agent SHALL first request all information, necessary for the authentication method, that will be used if the client's identity will not be identified during the TLS handshake (such information may include user name, password, etc.). Then, the TCP connection [RFC0793] SHALL be established to the particular POP3 server on the appropriate TCP port (or 995, if not explicitly specified). Once TCP connection is established, TLS handshake [RFC5246] SHALL be performed (POP3 client is serving as TLS client here). Upon successful TLS negotiation all data SHALL be sent over TLS layer. If the client has provided an X.509 certificate that can be successfully verified by the server, then the client and server SHALL enter the TRANSACTION state. In this case the server SHALL the "+OK" response directly after TLS negotiation. However, under some circumstances the client's identity cannot be identified by the X.509 certificate supplied during the TLS handshake. In this case the server SHALL AUTHORIZATION state; the client SHALL then also enter the AUTHORIZATION state and perform the authentication choosing the method (for instance, SASL [RFC4422][RFC5034]) according to its settings. {{TODO: How should the server indicate what state it enters?}} Melnikov & Yevstifeyev Expires November 16, 2011 [Page 3]
INTERNET DRAFT POP3 over TLS May 15, 2011 Anyway, as soon as client is authenticated and enters the TRANSACTION state, it begins exchanging POP3 commands and responses with the server under TLS layer. Please note that the user agent MUST NOT try to establish the SSL 2.0 connection during POP3S section, per RFC 6176 [RFC6176]. 2.2. Data Exchange All the data (explicitly, POP3 commands and responses), upon successful TLS negotiation, SHALL be sent as TLS "application data". 2.3. Connection Closure TLS provides the possibility for secure connection closure. Therefore, upon POP3S transaction closure, the client SHALL initiate the exchange of TLS close alerts, that happens before TCP connection termination. When the server receives the TLS close alert, it may be sure that no other data will be sent in this connection. The POP3 client MAY, after sending TLS close alert, terminate its part of connection without waiting a response from the server. 2.4. Default Port Historically, the separate TCP port has been used for POP3S - 995. Therefore if there is no explicit specification of port, the client SHALL connect the server on it. Section 4 of this document updates IANA registration of this port number with reference to this document in the corresponding registry. 2.5. POP3S Disadvantages Section 7 of RFC 2595 [RFC2595] contains a few words about the POP3S protocol. It discourages its usage in favor of STLS command, described in it, mainly claiming that POP3S, if implemented, would cause many misunderstandings regarding the need of new URI scheme, separate port numbers, etc. These issues are fully considered; however the usefulness of POP3S certainly overweighs these flaws. This specification updates RFC 2595; however, upon approval of this document, it does not ban the usage of STLS command described there - it and POP3S may be continued to be used simultaneously. 3. Security Considerations The POP3S protocol is primarily aimed to secure POP3 connection. This is achieved by sending data under TLS layer [RFC5246], that provides protection from eavesdropping, tampering, or message forgery Melnikov & Yevstifeyev Expires November 16, 2011 [Page 4]
INTERNET DRAFT POP3 over TLS May 15, 2011 (see RFC 4949 [RFC4949] for definitions of these terms). Moreover, a common POP3S scenario assumes that TLS negotiation also serves to authenticate the user agent. Because POP3S protocol supposes that authentication during TLS negotiation can also fail, it is allowed to use any other authentication schemes, such as Kerberos [RFC4752] (see Section 2 of this document). Please refer to Security consideration sections of such authentication schemes' specifications for discussion of security issues for such certain authentication schemes. 4. IANA Considerations IANA is asked to update the registration of the TCP well-known port 995 using the following template (see RFC nnnn [I.D. draft-ietf- tsvwg-iana-ports]): o Service Name: pop3s o Transport Protocol: TCP o Assignee: IETF <iesg@ietf.org> o Contact: IESG <iesg@ietf.org> o Description: POP3 over TLS protocol o Reference: RFC xxxx (this document - note to RFC Editor) o Port Number: 995 5. References 5.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. Melnikov & Yevstifeyev Expires November 16, 2011 [Page 5]
INTERNET DRAFT POP3 over TLS May 15, 2011 5.2. Informative References [I.D. draft-ietf-tsvwg-iana-ports] M. Cotton, L. Eggert, J. Touch, M. Westerlund and Cheshire, S., "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", work in progress [I.D. draft-mavrogiannopoulos-ssl-version3] A. Freier, P. Karlton and Kocher, P., "The SSL Protocol Version 3.0", work in progress Note to RFC Editor: Please don't publish this document until these drafts (above) become RFCs. This note SHALL be deleted. [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC4752] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, November 2006. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007. [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism", RFC 5034, July 2007. [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", RFC 6176, March 2011. Melnikov & Yevstifeyev Expires November 16, 2011 [Page 6]
INTERNET DRAFT POP3 over TLS May 15, 2011 Appendix A. Acknowledgments Many thanks to Chris Newman, <TBD> for their input to this document. Authors' Addresses Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK EMail: Alexey.Melnikov@isode.com Mykyta Yevstifeyev 8 Kuzovkov St., flat 25, Kotovsk Ukraine EMail: evnikita2@gmail.com Melnikov & Yevstifeyev Expires November 16, 2011 [Page 7]