Internet DRAFT - draft-melnikov-pop3-over-tls
draft-melnikov-pop3-over-tls
INTERNET-DRAFT A. Melnikov
Intended Status: Standards Track Isode Limited
Updates: 2595 (if approved) C. Newman
Expires: March 2, 2012 Oracle
M. Yevstifeyev, Ed.
August 30, 2011
POP3 over TLS
draft-melnikov-pop3-over-tls-02
Abstract
This document specifies how the Post Office Protocol, Version 3
(POP3) may be secured with Transport Layer Security (TLS) protocol,
by establishing TLS connection directly before POP3 transaction. 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
Melnikov et al. Expires March 2, 2012 [Page 1]
INTERNET DRAFT POP3 over TLS August 30, 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 and User Authentication . . . . . 3
2.2. Data Exchange . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Connection Closure . . . . . . . . . . . . . . . . . . . . 4
2.4. Default Port . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Disadvantages of POP3S . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The Post Office Protocol version 3 (POP3), which 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).
As POP3 is employed to transfer sensitive information, there is a
need for privacy protection. Transport Layer Security (TLS)
[RFC5246] (and its predecessor Secure Sockets Layer (SSL) [RFC6101])
are commonly used for this purpose.
Two ways of protecting POP3 with TLS 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) [RFC2595]. The other one involves
establishing TLS connection directly before establishing POP3
transaction. Unlike the former, this way (called "POP3S" throughout
this document) has not been previously specified in an RFC. (In the
case with HTTP the first way is specified in RFC 2817 [RFC2817]; the
second one - in RFC 2818 [RFC2818].)
This document specifies POP3S. It updates RFC 2595 [RFC2595] (see
Section 2.5 for justification). This memo also updates the
Melnikov et al. Expires March 2, 2012 [Page 2]
INTERNET DRAFT POP3 over TLS August 30, 2011
registration of the TCP well-known port 995, used with POP3S.
RFC 6186 [RFC6186] specifies the way to use DNS SRV records [RFC2782]
for locating information about email access services. It supports
both POP3S and the aforementioned POP3 upgraded to TLS. For more
information, refer to Section 3.3 of RFC 6186.
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].
Terminology from RFC 1939 [RFC1939] is used in this document.
The "POP3S transaction" refers to the POP3 transaction established as
described in Section 2.1.
2. POP3 over TLS Protocol
This section contains the technical definition of POP3 over TLS
protocol (POP3S).
2.1. Connection Establishment and User Authentication
This section describes how to establish POP3S transaction.
First, the client first establishes the TCP connection [RFC0793] to
the server on the 995 port, or other, if explicitly mentioned. As
soon as successful connection is established, the TLS negotiation
[RFC5246] SHALL be preformed. RFC nnnn [I-D.melnikov-email-tls-
certs] describes the procedure which MUST be followed by the clients
to verify the server's certificate. Upon successful negotiation all
data SHALL be sent under TLS layer, as defined in Section 2.2.
Unsuccessful TLS negotiation SHALL lead to termination of TCP
connection.
As soon as successful TLS layer connection is established, the server
sends the greeting line, as defined by RFC 1939. Both the server and
the client MUST enter AUTHORIZATION state then.
Next, the client should authorize itself to the server. If there is
a bilateral convention between the parties regarding authorization
using X.509 certificate, the client SHOULD first try to authorize
itself using SASL EXTERNAL mechanism, which is defined in Appendix A
of RFC 4422 [RFC4422]. For this purpose, the AUTH command [RFC5034]
SHALL be used. (Correspondingly, those servers and clients which
support authentication using X.509 certificates MUST support the SASL
EXTERNAL mechanism.) Servers that lack configuration to accept an
Melnikov et al. Expires March 2, 2012 [Page 3]
INTERNET DRAFT POP3 over TLS August 30, 2011
X.509 client certificate for authentication purposes SHOULD NOT send
a CertificateRequest handshake to the client during TLS negotiation.
However, if SASL EXTERNAL authentication fails, or there was no
certificate exchange during TLS negotiation, the client MAY either
close the connection or try a different authentication mechanism
(e.g., USER and PASS commands).
After the client has received the +OK response to the authentication
command, both the client and server MUST enter TRANSACTION state, per
RFC 1939.
SSL 2.0 MUST NOT be used for POP3S; see RFC 6176 [RFC6176] for
details.
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, which should happen 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 for a response from
the server.
2.4. Default Port
POP3S uses the default port 995. Section 4 updates the IANA
registration for this port.
2.5. Disadvantages of POP3S
Section 7 of RFC 2595 [RFC2595] expresses concerns about use of a
separate port for POP3S. The concern about port usage does not apply
as port 995 was previously registered. RFC 6186 mitigates the other
concerns. The usefulness of POP3S outweighs these flaws so the
statement in section 7 of RFC 2595 discouraging use of POP3S is
rescinded.
3. Security Considerations
POP3S uses TLS [RFC5246] to provide protection from eavesdropping and
Melnikov et al. Expires March 2, 2012 [Page 4]
INTERNET DRAFT POP3 over TLS August 30, 2011
tampering with POP3 protocol content. The security considerations of
TLS [RFC5246] and those related to server identity verification
[RFC6125][I-D.melnikov-email-tls-certs] apply.
4. IANA Considerations
IANA is asked to update the registration of the TCP well-known port
995 using the following template (see RFC 6335 [RFC6335]):
Service Name: pop3s
Transport Protocol: TCP
Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Description: POP3 over TLS protocol
Reference: RFC xxxx (this document - note to RFC Editor)
Port Number: 995
5. References
5.1. Normative References
[I-D.melnikov-email-tls-certs]
Melnikov, A., "Updated TLS Server Identity Check
Procedure for Email Related Protocols", Work in Progress
(draft-melnikov-email-tls-certs), June 2011.
[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.
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422, June
2006.
[RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office
Protocol (POP3) Simple Authentication and Security Layer
(SASL) Authentication Mechanism", RFC 5034, July 2007.
Melnikov et al. Expires March 2, 2012 [Page 5]
INTERNET DRAFT POP3 over TLS August 30, 2011
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
5.2. Informative References
[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.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[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.
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
August 2011.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
(SSL) Version 2.0", RFC 6176, March 2011.
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email
Submission/Access Services", RFC 6186, March 2011.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M. and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC
6335, July 2011.
Appendix A. Acknowledgments
We would like to thank Randall Gellens and Paul Smith for their
discussion of, ideas for and suggestions to this document.
Melnikov et al. Expires March 2, 2012 [Page 6]
INTERNET DRAFT POP3 over TLS August 30, 2011
Authors' Addresses
Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
EMail: Alexey.Melnikov@isode.com
Chris Newman
Oracle
800 Royal Oaks
Monrovia, CA 91016-6347
US
EMail: chris.newman@oracle.com
Mykyta Yevstifeyev (editor)
8 Kuzovkov St., Apt. 25
Kotovsk
Ukraine
EMail: evnikita2@gmail.com
Melnikov et al. Expires March 2, 2012 [Page 7]
