idnits 2.17.00 (12 Aug 2021) /tmp/idnits6559/draft-melnikov-pop3-over-tls-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2595, updated by this document, for RFC5378 checks: 1997-08-28) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 30, 2011) is 3910 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'I-D.melnikov-email-tls-certs' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT A. Melnikov 3 Intended Status: Standards Track Isode Limited 4 Updates: 2595 (if approved) C. Newman 5 Expires: March 2, 2012 Oracle 6 M. Yevstifeyev, Ed. 7 August 30, 2011 9 POP3 over TLS 10 draft-melnikov-pop3-over-tls-02 12 Abstract 14 This document specifies how the Post Office Protocol, Version 3 15 (POP3) may be secured with Transport Layer Security (TLS) protocol, 16 by establishing TLS connection directly before POP3 transaction. It 17 updates RFC 2595. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. POP3 over TLS Protocol . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Connection Establishment and User Authentication . . . . . 3 61 2.2. Data Exchange . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.3. Connection Closure . . . . . . . . . . . . . . . . . . . . 4 63 2.4. Default Port . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.5. Disadvantages of POP3S . . . . . . . . . . . . . . . . . . 4 65 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 67 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5.1. Normative References . . . . . . . . . . . . . . . . . . . 5 69 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 70 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 The Post Office Protocol version 3 (POP3), which is defined in RFC 76 1939 [RFC1939], is an application-layer protocol used by local e-mail 77 clients to retrieve e-mail from a remote server over a simple TCP/IP 78 connection. It supports simple download-and-delete requirements for 79 access to remote mailboxes (also called a maildrop). 81 As POP3 is employed to transfer sensitive information, there is a 82 need for privacy protection. Transport Layer Security (TLS) 83 [RFC5246] (and its predecessor Secure Sockets Layer (SSL) [RFC6101]) 84 are commonly used for this purpose. 86 Two ways of protecting POP3 with TLS have been deployed (like 2 ways 87 of securing HTTP [RFC2616]; see below). The first includes 88 establishing TLS layer connection during the POP3 transaction (also 89 known as upgrading to TLS) [RFC2595]. The other one involves 90 establishing TLS connection directly before establishing POP3 91 transaction. Unlike the former, this way (called "POP3S" throughout 92 this document) has not been previously specified in an RFC. (In the 93 case with HTTP the first way is specified in RFC 2817 [RFC2817]; the 94 second one - in RFC 2818 [RFC2818].) 96 This document specifies POP3S. It updates RFC 2595 [RFC2595] (see 97 Section 2.5 for justification). This memo also updates the 98 registration of the TCP well-known port 995, used with POP3S. 100 RFC 6186 [RFC6186] specifies the way to use DNS SRV records [RFC2782] 101 for locating information about email access services. It supports 102 both POP3S and the aforementioned POP3 upgraded to TLS. For more 103 information, refer to Section 3.3 of RFC 6186. 105 1.1. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 Terminology from RFC 1939 [RFC1939] is used in this document. 112 The "POP3S transaction" refers to the POP3 transaction established as 113 described in Section 2.1. 115 2. POP3 over TLS Protocol 117 This section contains the technical definition of POP3 over TLS 118 protocol (POP3S). 120 2.1. Connection Establishment and User Authentication 122 This section describes how to establish POP3S transaction. 124 First, the client first establishes the TCP connection [RFC0793] to 125 the server on the 995 port, or other, if explicitly mentioned. As 126 soon as successful connection is established, the TLS negotiation 127 [RFC5246] SHALL be preformed. RFC nnnn [I-D.melnikov-email-tls- 128 certs] describes the procedure which MUST be followed by the clients 129 to verify the server's certificate. Upon successful negotiation all 130 data SHALL be sent under TLS layer, as defined in Section 2.2. 131 Unsuccessful TLS negotiation SHALL lead to termination of TCP 132 connection. 134 As soon as successful TLS layer connection is established, the server 135 sends the greeting line, as defined by RFC 1939. Both the server and 136 the client MUST enter AUTHORIZATION state then. 138 Next, the client should authorize itself to the server. If there is 139 a bilateral convention between the parties regarding authorization 140 using X.509 certificate, the client SHOULD first try to authorize 141 itself using SASL EXTERNAL mechanism, which is defined in Appendix A 142 of RFC 4422 [RFC4422]. For this purpose, the AUTH command [RFC5034] 143 SHALL be used. (Correspondingly, those servers and clients which 144 support authentication using X.509 certificates MUST support the SASL 145 EXTERNAL mechanism.) Servers that lack configuration to accept an 146 X.509 client certificate for authentication purposes SHOULD NOT send 147 a CertificateRequest handshake to the client during TLS negotiation. 149 However, if SASL EXTERNAL authentication fails, or there was no 150 certificate exchange during TLS negotiation, the client MAY either 151 close the connection or try a different authentication mechanism 152 (e.g., USER and PASS commands). 154 After the client has received the +OK response to the authentication 155 command, both the client and server MUST enter TRANSACTION state, per 156 RFC 1939. 158 SSL 2.0 MUST NOT be used for POP3S; see RFC 6176 [RFC6176] for 159 details. 161 2.2. Data Exchange 163 All the data (explicitly, POP3 commands and responses), upon 164 successful TLS negotiation, SHALL be sent as TLS "application data". 166 2.3. Connection Closure 168 TLS provides the possibility for secure connection closure. 169 Therefore, upon POP3S transaction closure, the client SHALL initiate 170 the exchange of TLS close alerts, which should happen before TCP 171 connection termination. When the server receives the TLS close 172 alert, it may be sure that no other data will be sent in this 173 connection. The POP3 client MAY, after sending TLS close alert, 174 terminate its part of connection without waiting for a response from 175 the server. 177 2.4. Default Port 179 POP3S uses the default port 995. Section 4 updates the IANA 180 registration for this port. 182 2.5. Disadvantages of POP3S 184 Section 7 of RFC 2595 [RFC2595] expresses concerns about use of a 185 separate port for POP3S. The concern about port usage does not apply 186 as port 995 was previously registered. RFC 6186 mitigates the other 187 concerns. The usefulness of POP3S outweighs these flaws so the 188 statement in section 7 of RFC 2595 discouraging use of POP3S is 189 rescinded. 191 3. Security Considerations 193 POP3S uses TLS [RFC5246] to provide protection from eavesdropping and 194 tampering with POP3 protocol content. The security considerations of 195 TLS [RFC5246] and those related to server identity verification 196 [RFC6125][I-D.melnikov-email-tls-certs] apply. 198 4. IANA Considerations 200 IANA is asked to update the registration of the TCP well-known port 201 995 using the following template (see RFC 6335 [RFC6335]): 203 Service Name: pop3s 205 Transport Protocol: TCP 207 Assignee: IETF 209 Contact: IESG 211 Description: POP3 over TLS protocol 213 Reference: RFC xxxx (this document - note to RFC Editor) 215 Port Number: 995 217 5. References 219 5.1. Normative References 221 [I-D.melnikov-email-tls-certs] 222 Melnikov, A., "Updated TLS Server Identity Check 223 Procedure for Email Related Protocols", Work in Progress 224 (draft-melnikov-email-tls-certs), June 2011. 226 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 227 RFC 793, September 1981. 229 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 230 3", STD 53, RFC 1939, May 1996. 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple 236 Authentication and Security Layer (SASL)", RFC 4422, June 237 2006. 239 [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office 240 Protocol (POP3) Simple Authentication and Security Layer 241 (SASL) Authentication Mechanism", RFC 5034, July 2007. 243 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 244 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 246 5.2. Informative References 248 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 249 RFC 2595, June 1999. 251 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 252 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 253 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 255 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 256 specifying the location of services (DNS SRV)", RFC 2782, 257 February 2000. 259 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 260 HTTP/1.1", RFC 2817, May 2000. 262 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 264 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 265 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 266 August 2011. 268 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 269 Verification of Domain-Based Application Service Identity 270 within Internet Public Key Infrastructure Using X.509 271 (PKIX) Certificates in the Context of Transport Layer 272 Security (TLS)", RFC 6125, March 2011. 274 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 275 (SSL) Version 2.0", RFC 6176, March 2011. 277 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 278 Submission/Access Services", RFC 6186, March 2011. 280 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M. and S. 281 Cheshire, "Internet Assigned Numbers Authority (IANA) 282 Procedures for the Management of the Service Name and 283 Transport Protocol Port Number Registry", BCP 165, RFC 284 6335, July 2011. 286 Appendix A. Acknowledgments 288 We would like to thank Randall Gellens and Paul Smith for their 289 discussion of, ideas for and suggestions to this document. 291 Authors' Addresses 293 Alexey Melnikov 294 Isode Limited 295 5 Castle Business Village 296 36 Station Road 297 Hampton, Middlesex TW12 2BX 298 UK 300 EMail: Alexey.Melnikov@isode.com 302 Chris Newman 303 Oracle 304 800 Royal Oaks 305 Monrovia, CA 91016-6347 306 US 308 EMail: chris.newman@oracle.com 310 Mykyta Yevstifeyev (editor) 311 8 Kuzovkov St., Apt. 25 312 Kotovsk 313 Ukraine 315 EMail: evnikita2@gmail.com