INTERNET-DRAFT M. Yevstifeyev Intended Status: Standards Track February 13, 2011 Updates: 2595 (if approved) Expires: August 17, 2011 The 'pops' URI Scheme Abstract This document specifies the 'pops' URI scheme, that is used to designate the access to POP3 mailboxes over TLS. It updates 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 Expires August 17, 2011 [Page 1] INTERNET DRAFT The 'pops' URI Scheme February 13, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. The 'pops' URI Scheme Definition . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . . 5 5.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Yevstifeyev Expires August 17, 2011 [Page 2] INTERNET DRAFT The 'pops' URI Scheme February 13, 2011 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 TCP/IP connection. However since the time of appearance of this protocol, it has been widely implemented over Transport Layer Security (TLS) [RFC5246] (see RFC 2595 [RFC2595] for details) and its deprecated predecessor Secure Sockets Layer (SSL). 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 Transmission Control Protocol (TCP) [RFC793] operations; not aforementioned POP3 over TLS binding. This document specifies the URI scheme used for referencing the POP3 mailboxes that are available using POP3 over TLS binding, as described in RFC 2595 [RFC2595]. It updates that document. Generic URI syntax is described in RFC 3986 [RFC3986]. Procedures for registration of new URI schemes are defined in RFC 4395 [RFC4395]. 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]. Yevstifeyev Expires August 17, 2011 [Page 3] INTERNET DRAFT The 'pops' URI Scheme February 13, 2011 2. The 'pops' URI Scheme Definition The 'pops' URI scheme is used to designate the access to POP3 [RFC1939] mailboxes that are available via the POP3 over TLS binding, as described in RFC 2595 [RFC2595]. Therefore the user agent, using the 'pops' URI, SHOULD firstly request the password (and the user name, if not given in the URI) from the client and then SHALL establish the POP3 transaction as described in that document - i. e. firstly establish the usual TCP [RFC793] connection, open the POP3 transaction, send STLS command, begin TLS handshake, identify itself using the credentials requested before and then send all the data under TLS layer [RFC5246]. There is already the 'pop' URI scheme used for referencing the POP3 mailboxes over usual TCP connection [RFC2384]. Since the 'pops' URI scheme defined by this document is used to provide the access to the same resources as 'pop' one (i. e. POP3 mailboxes), only using different connection types, the syntax of these schemes are the same either, except the 'scheme' part. It is described using Augmented Backus-Naur Form (ABNF) [RFC5234] as follows: pops-uri = scheme ":" hier-part scheme = "pops" hier-part = "//" [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 RFC 3986 [RFC3986], Appendix A. The core rules 'ALPHA' and 'DIGIT' are used as described in RFC 5234 [RFC5234], Appendix B. If 'port' part is omitted, it SHALL default to 110. If the characters ";" and ":" appear in the 'user' part, they MUST be percent-encoded, as described in Section 2.1 of RFC 3986 [RFC3986]. 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 connection. The ";AUTH:*" assumes that no special authentication mechanism SHOULD be used - 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 Yevstifeyev Expires August 17, 2011 [Page 4] INTERNET DRAFT The 'pops' URI Scheme February 13, 2011 establishing the connection, as described below. If the 'auth' part does not starts with "+", the Simple Authentication and Security Layer (SASL) [RFC4422] SHOULD be used for authentication. If the 'auth' 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. 3. 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 sending user credentials over such connection. More security issues may be added by other authentication mechanisms for POP3. These mechanism are not discussed by this memo. 4. IANA Considerations 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 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 'tn3270' one as well. Non-ASCII characters are to be mapped as defined in Section 3.1 of RFC 3987 [RFC3987] Protocols that use the scheme: POP3 over TLS connections [RFC2595] Security considerations: see Section 3 of RFC xxxx Yevstifeyev Expires August 17, 2011 [Page 5] INTERNET DRAFT The 'pops' URI Scheme February 13, 2011 Contact: IESG Author/Change controller: IETF References: see Section 5 of RFC xxxx [RFC Editor: Replace xxxx with assigned RFC number] 5. References 5.1. Normative References [RFC793] 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] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999. [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. [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [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. 5.2. Informative References [RFC2384] Gellens, R., "POP URL Scheme", RFC 2384, August 1998. Yevstifeyev Expires August 17, 2011 [Page 6] INTERNET DRAFT The 'pops' URI Scheme February 13, 2011 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006. Appendix A. Acknowledgments Many thanks for /TBD/ for their input to this document. Author's Addresses Mykyta Yevstifeyev 8 Kuzovkov St., flat 25, Kotovsk, Ukraine EMail: evnikita2@gmail.com Yevstifeyev Expires August 17, 2011 [Page 7]