INTERNET-DRAFT M. Yevstifeyev Intended Status: Standards Track Updates: 1939, 2595 (if approved) A. Melnikov Expires: October 8, 2011 Isode Limited April 6, 2011 POP3 over TLS and 'pops' URI Scheme <draft-yevstifeyev-pops-uri-scheme-03> Abstract This document specifies the POP3 over TLS protocol (pop3s) and corresponding 'pops' URI scheme. 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 to this document. Code Components extracted from this document must Yevstifeyev & Melnikov Expires October 8, 2011 [Page 1]
INTERNET DRAFT POP3 over TLS & 'pops' URI Scheme April 6, 2011 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 3. The 'pops' URI Scheme . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5.1. URI Scheme Registration . . . . . . . . . . . . . . . . . 5 5.2. Port Number Assignment Update . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 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. However, since the time of appearance of this protocol, firstly defined in RFC 1081 [RFC1081], it has been widely implemented over Transport Layer Security (TLS) (including the most current version 1.2 [RFC5246] as well as outdated TLS 1.1 [RFC4346] and TLS 1.0 [RFC2246]) and its deprecated predecessor Secure Sockets Layer (SSL) [SSL]. However such mode of POP3 session has not been properly specified. This document is to remove this uncertainty; it gives the distinctive definition of the POP3 over TLS protocol (called "pop3s" throughout this document). This memo updates RFC 1939 [RFC1939]. RFC 2595 [RFC2595] is also updated by this document (see Section 2 for justification). RFC 2384 [RFC2384] already defines the Uniform Resource Identifier (URI) 'pop' scheme that is used for referencing the POP3 mailboxes. However this scheme supports only usual POP3 over TCP [RFC0793] operations; not aforementioned pop3s. This document specifies the URI scheme used for referencing the POP3 mailboxes that are available using it and the procedure the user agent should follow while establishing of pop3s connection - POP3 over TLS transport binding. Yevstifeyev & Melnikov Expires October 8, 2011 [Page 2]
INTERNET DRAFT POP3 over TLS & 'pops' URI Scheme April 6, 2011 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 definition of POP3 over TLS protocol (pop3s) (transport binding). Those user agents that are compatible with the pop3s protocol, described in this document, SHALL follow the following procedure while establishing the connection (it is also called POP3 over TLS transport binding). It is assumed that the resource accessible by this protocol is identified by 'pops' URI, as described in Section 3. Firstly, the user agent SHALL request the password (and user name, if not given in the URI) or other necessary information for the used authentication method, that will be used if the client's identity will not be identified during the TLS handshake. Then, the TCP connection [RFC0793] SHALL be established to the endpoint, identified as <host> in the URI to the port identified in the <port> part of the 'pops' URI (or 995, if not given there). Once TCP connection is established, TLS handshake [RFC5246] SHALL be performed. 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 server SHALL enter the TRANSACTION state. However in some circumstances the client's identity cannot be identified by the X.509 certificate supplied during the TLS handshake. In this case the user agent SHALL enter the AUTHORIZATION state and performs the authentication according to the <user-auth> part of 'pops' URI or the user agent's settings just after TLS handshake. Anyway, as soon as client is authenticated and enters the TRANSACTION state, it begins exchanging POP3 commands and responses 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]. 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, Yevstifeyev & Melnikov Expires October 8, 2011 [Page 3]
INTERNET DRAFT POP3 over TLS & 'pops' URI Scheme April 6, 2011 separate port numbers, etc. However, none of these recommendations were put in action; pop3s protocol has been widely implemented so far, even being undocumented. This document updates RFC 2595 [RFC2595] and obsoletes its Section 7. But, upon approval of this document, it does not ban the usage of STLS command described in RFC 2595 [RFC2595]; it and pop3s protocol MAY be used simultaneously. 3. The 'pops' URI Scheme The 'pops' URI scheme is used to designate the access to POP3 [RFC1939] mailboxes available via the pop3s protocol. There is already the 'pop' URI scheme used for referencing the POP3 mailboxes over usual TCP connection [RFC2384], as mentioned above. Since they both identify the same resource, only using different connection types, their syntax is the same, except the <scheme> part. The 'pops' URI is described using Augmented Backus-Naur Form (ABNF) [RFC5234] as follows: pops-uri = "pops:" "//" [user-auth "@"] host [":" port] ["/"] user-auth = user [auth] user = 1*achar auth = ";AUTH=" ("*" / auth-type) auth-type = auth-sasl / auth-ext auth-sasl = 1*achar auth-ext = "+" ("APOP" / 1*achar) achar = ALPHA / DIGIT / pct-encoded / "$" / "-" / "_" / "." / "+" / "!" / "'" / "(" / ")" / "," / "=" / "*" / "~" / "&" The <host>, <port> and <pct-encoded> rules are described in Appendix A of RFC 3986 [RFC3986]. The core rules <ALPHA> and <DIGIT> are used as described in Appendix B of RFC 5234 [RFC5234]. Note: The <achar> rule contains the characters permitted in the <userinfo> production of RFC 3986 [RFC3986] except the ";" character. This is made in order not to create confusion with <auth> part, that uses ";" as the delimiter. If <port> part is omitted, it SHALL default to 995. If the characters, not listed in the <achar> rule, appear in the <user> part, they MUST be percent-encoded. The final character "/" MAY be omitted. The <auth> part of the 'pops' URIs allows to choose what authentication mechanism will be used after the establishing the Yevstifeyev & Melnikov Expires October 8, 2011 [Page 4]
INTERNET DRAFT POP3 over TLS & 'pops' URI Scheme April 6, 2011 connection, if the client's identity is not properly identified during TLS handshake. The ";AUTH=*" or the absence of the <auth> part assumes that no special authentication mechanism should be used in such case - i. e. the user name and password should be transmitted via the USER and PASS commands, respectively. If another authentication type is assumed, it SHOULD be used after the establishing the connection in the aforementioned case, as described below. If the <auth-type> part does not starts with "+", the Simple Authentication and Security Layer (SASL) [RFC5034] SHOULD be used for authentication. See RFC 4422 [RFC4422] for more information on SASL itself. If the <auth-type> part starts with "+", that APOP or other specified external authentication mechanism SHOULD be assumed to be used. Please note that the user agent MAY use another authentication mechanism than defined in the 'pops' URI if it is properly set. 4. Security Considerations Generic security considerations for the usage of URIs are discussed in Section 7 of RFC 3986 [RFC3986]. The 'pops' URI designates the secure TLS connection for POP3 transaction. Moreover, it allows to choose what authentication mechanism SHOULD be used for user authentication over such connection. More security issues may be added by other authentication mechanisms for POP3. These mechanism are not discussed by this memo. 5. IANA Considerations 5.1. URI Scheme Registration IANA is asked to register the 'pops' URI scheme using the following template (see RFC 4395 [RFC4395]): URI scheme name: pops Status: Permanent URI scheme syntax: see Section 2 of RFC xxxx Yevstifeyev & Melnikov Expires October 8, 2011 [Page 5]
INTERNET DRAFT POP3 over TLS & 'pops' URI Scheme April 6, 2011 URI scheme semantics: see Section 2 of RFC xxxx URI scheme encoding considerations: Generic encoding considerations for URI schemes, defined in Section 2 of [RFC3986], concern 'pops' one as well. Non-ASCII characters are to be mapped as defined in Section 3.1 of RFC 3987 [RFC3987]. Note that there are the restrictions for usage of some characters in the <user> part of the URI - see Section 3 Protocols that use the scheme: POP3 over TLS connections, as described in RFC xxxx Security considerations: see Section 3 of RFC xxxx Contact: IESG <iesg@ietf.org> Author/Change controller: IETF <ietf@ietf.org> References: see Section 5 of RFC xxxx [RFC Editor: Replace xxxx with assigned RFC number] 5.2. Port Number Assignment Update 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]): Service Name: pop3s Transport Protocol: TCP Assignee: IETF <iesg@ietf.org> Contact: IESG <iesg@ietf.org> Description: POP3 over TLS protocol Reference: RFC xxxx Port Number: 995 6. References 6.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC Yevstifeyev & Melnikov Expires October 8, 2011 [Page 6]
INTERNET DRAFT POP3 over TLS & 'pops' URI Scheme April 6, 2011 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. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism", RFC 5034, July 2007. [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 6.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 Note to RFC Editor: Please hold this document in the publication queue until this draft becomes an RFC. This note SHALL be deleted. [RFC1081] Rose, M., "Post Office Protocol: Version 3", RFC 1081, November 1988. Obsoleted by RFC1225. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. Obsoleted by RFC4346. [RFC2384] Gellens, R., "POP URL Scheme", RFC 2384, August 1998. Yevstifeyev & Melnikov Expires October 8, 2011 [Page 7]
INTERNET DRAFT POP3 over TLS & 'pops' URI Scheme April 6, 2011 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. Obsoleted by RFC5246. [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006. [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", RFC 6176, March 2011. [SSL] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., November 1996. Appendix A. Acknowledgments Many thanks to Chris Newman, <TBD> for their input to this document. Authors' Addresses Mykyta Yevstifeyev 8 Kuzovkov St., flat 25, Kotovsk Ukraine EMail: evnikita2@gmail.com Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK EMail: Alexey.Melnikov@isode.com Yevstifeyev & Melnikov Expires October 8, 2011 [Page 8]
