[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-yevstifeyev-pops-uri-scheme) 00 01 02

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/