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