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
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.
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]
