idnits 2.17.00 (12 Aug 2021) /tmp/idnits45583/draft-newman-tls-imappop-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 1997) is 8952 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) == Missing Reference: 'POP3-AUTH' is mentioned on line 193, but not defined == Unused Reference: 'IMAIL' is defined on line 280, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ABNF' ** Obsolete normative reference: RFC 822 (ref. 'IMAIL') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) -- Possible downref: Non-RFC (?) normative reference: ref. 'POP3EXT' ** Obsolete normative reference: RFC 1734 (ref. 'POP-AUTH') (Obsoleted by RFC 5034) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: Using TLS with IMAP4 and POP3 Innosoft 4 Document: draft-newman-tls-imappop-01.txt November 1997 6 Using TLS with IMAP4 and POP3 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as "work in 19 progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 Copyright Notice 29 Copyright (C) The Internet Society 1997. All Rights Reserved. 31 Introduction 33 The TLS protocol [TLS] (formerly known as SSL) provides a way to 34 secure a connection from tampering and evesdropping. Obviously, 35 such security is desirable for IMAP [IMAP4] and POP [POP3]. 36 Although advanced authentication mechanisms [IMAP-AUTH, POP-AUTH] 37 can provide this service with less complexity than TLS, TLS is 38 useful in combination with plaintext password logins and other 39 simple mechanisms as it doesn't require a site to upgrade its 40 authentication database. 42 The common practice of using a separate port for a secure version 43 of each protocol has a number of disadvantages in the IMAP [IMAP4] 44 and POP [POP3] environment. Rather than using the best security 45 available, it means that clients have to be explicitly configured 46 to use the separate secure port or suffer the performance loss of 47 probing for active ports. For IMAP, this is even more serious as 48 it would require a new URL scheme which could only be resolved by 49 TLS-enabled clients. 51 This specification defines extensions to IMAP4 and POP3 which 52 activate TLS. It also defines a set of server security policy 53 response codes for use with IMAP4. The response codes MAY be used 54 independently of the TLS extension. 56 1. Conventions Used in this Document 58 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 59 NOT", and "MAY" in this document are to be interpreted as described 60 in "Key words for use in RFCs to Indicate Requirement Levels" 61 [KEYWORDS]. 63 Formal syntax is defined using ABNF [ABNF]. 65 In examples, "C:" and "S:" indicate lines sent by the client and 66 server respectively. 68 2. Cipher Suite Requirements 70 This application profile of TLS follows the standard "Mandatory 71 Cipher Suites" requirement as documented in the TLS specification 72 [TLS]. Implementations MUST NOT assume any other cipher suites are 73 present. It is possible that due to certain government export 74 restrictions some non-compliant versions of this extension could be 75 deployed. Implementations wishing to interoperate with such non- 76 compliant versions MAY offer the 77 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA mechanism. However, since 40 78 bit ciphers are known to be vulnerable to attack by current 79 technology, any client which actives a 40 bit cipher MUST NOT 80 indicate to the user that the connection is completely secure from 81 evesdropping. 83 3. IMAP4 STARTTLS extension 85 When the TLS extension is present in IMAP4, "STARTTLS" is listed as 86 a capability in response to the CAPABILITY command. This extension 87 adds a single command, "STARTTLS" to the IMAP4 protocol which is 88 used to begin a TLS negotiation. 90 3.1. STARTTLS Command 92 Arguments: none 94 Responses: no specific responses for this command 96 Result: OK - begin TLS negotiation 97 NO - security layer already active 98 BAD - command unknown or arguments invalid 100 A TLS negotiation begins immediately after the CRLF at the end of 101 the tagged OK response from the server. The STARTTLS command MAY 102 be used in any state. However, a NO response MAY result if a 103 security layer is already active. Once a client issues a STARTTLS 104 command, it MUST NOT issue further commands until a server 105 response is seen. 107 If STARTTLS is issued in non-authenticated state, the server 108 remains in non-authenticated state, even if client credentials are 109 supplied during the TLS negotiation. The SASL [SASL] EXTERNAL 110 mechanism MAY be used to authenticate once TLS client credentials 111 are successfully exchanged, but servers supporting the STARTTLS 112 command are not required to support the EXTERNAL mechanism. 114 The formal syntax for IMAP4 is amended as follows: 116 command_any =/ "STARTTLS" 118 Example: C: a001 CAPABILITY 119 S: * CAPABILITY IMAP4rev1 STARTTLS 120 S: a001 OK CAPABILITY completed 121 C: a002 STARTTLS 122 S: a002 OK Begin TLS negotiation now 123 124 C: a003 LOGIN joe password 125 S: a003 OK LOGIN completed 127 4. New IMAP4 response codes 129 This specification defines three new IMAP4 response codes which 130 MAY be used to communicate server security policy to the client. 131 These MAY be implemented independently of the STARTTLS command. 133 PASS-EXPIRED 134 This occurs on a tagged NO response to an AUTHENTICATE or 135 LOGIN command and indicates the password supplied has expired 136 and needs to be changed. 138 ENCRYPT-NEEDED 139 This occurs on a tagged NO response to an AUTHENTICATE or 140 LOGIN command and indicates that the requested authentication 141 mechanism is only permitted underneath a security layer. The 142 client MAY then issue the STARTTLS command and repeat the 143 same AUTHENTICATE or LOGIN command, or try an AUTHENTICATE 144 command with a stronger mechanism. The client SHOULD record 145 the fact that encryption is needed for that user, server and 146 mechanism combination. 148 AUTH-TOO-WEAK 149 This occurs on a tagged NO response to an AUTHENTICATE or 150 LOGIN command and indicates that the mechanism is too weak 151 and is no longer permitted for that user by site policy. 152 This allows a mechanism to be disabled on a per-user rather 153 than a per-server level which is useful if different users 154 have different security requirements or for transitioning 155 from plaintext LOGIN to a more secure mechanism. The client 156 SHOULD record the fact that the user, server and mechanism 157 combination is no longer permitted. 159 TRANSITION-NEEDED 160 This occurs on a tagged NO response to an AUTHENTICATE 161 command. It indicates that the server has an entry for the 162 specified user in a legacy authentication database but does 163 not yet have credentials to offer the requested mechanism. A 164 client which receives this error code MAY do a one-time login 165 using the LOGIN command or another plaintext mechanism 166 (preferably protected by the STARTTLS command) to initialize 167 credentials for the requested mechanism. 169 5. POP3 STARTTLS extension 171 The POP3 STARTTLS extension adds the STLS command to POP3 servers. 172 If this is implemented, the POP3 extension mechanism [POP3EXT] SHOULD 173 also be implemented to avoid the need for client probing. 175 STLS 177 Arguments: none 179 Restrictions: 180 MAY be given in any state, but MAY fail if a security layer 181 is already active. 183 Discussion: 184 A TLS negotiation begins immediately after the CRLF at the 185 end of the +OK response from the server. A -ERR response 186 MAY result if a security layer is already active. Once a 187 client issues a STLS command, it MUST NOT issue further 188 commands until a server response is seen. 190 If STLS is issued in authorization state, the server 191 remains in authorization state, even if client credentials 192 are supplied during the TLS negotiation. The AUTH command 193 [POP3-AUTH] with the EXTERNAL mechanism [SASL] MAY be used 194 to authenticate once TLS client credentials are 195 successfully exchanged, but servers supporting the STLS 196 command are not required to support the EXTERNAL mechanism. 198 Possible Responses: 199 +OK -ERR 201 Examples: 202 C: STLS 203 S: +OK Begin TLS negotiation 204 205 ... 206 C: STLS 207 S: -ERR Security Layer already active 209 6. POP3 response codes 211 This uses the POP3 response codes defined in [POP3EXT]. 213 7. imaps and pop3s ports 215 Separate "imaps" and "pop3s" ports were registered for use with 216 TLS. Use of these ports is discouraged in favor of the STARTTLS 217 command. 219 One of the arguments used in favor of the separate port technique 220 is that it simplifies configuration of firewalls which filter by IP 221 port. However, a quality server implementation running on the 222 standard port can be configured to require use of the STARTTLS 223 command or a suitably strong SASL mechanism for non-local 224 connections. This provides superior functionality as the client 225 need not be re-configured for use outside the firewall and simpler, 226 faster non-plaintext SASL mechanisms may be acceptable to many 227 sites for non-local connections. 229 8. Security Considerations 230 The mechanisms described in this document only apply to protecting 231 a single connection. Messages are still available to server 232 administrators and usually subject to evesdropping, tampering and 233 forgery when transmitted through SMTP or NNTP. Protecting messages 234 requires an object security mechanism such as PGP MIME [PGP-MIME]. 236 An active attacker for IMAP can remove STARTTLS from the IMAP 237 CAPABILITY list, or cause the POP3 STLS command to fail with a 238 message such as "-ERR Unknown command." In order to detect such an 239 attack, clients SHOULD either warn the user when session protection 240 is not active, or be configurable to refuse to proceed without an 241 acceptable level of security. 243 If a client uses a weak mechanism which sends the user name at the 244 same time as the authentication credentials, such as IMAP4's LOGIN 245 command, the ENCRYPT-NEEDED or AUTH-TOO-WEAK error codes will not 246 prevent exposure. For this reason, clients SHOULD record the fact 247 that that user, server and mechanism combination is unacceptable to 248 prevent future exposure or be configurable to try stronger 249 mechanisms or activate encryption first. 251 An active attacker could cause a bogus TRANSITION-NEEDED response 252 to a stronger authentication mechanism. For this reason, clients 253 SHOULD either activate TLS prior to authentication or get explicit 254 permission from the user prior to using a plaintext mechanism for 255 automated transition. 257 An attacker might probe for users at a site by trying a strong 258 authentication mechanism which could result in TRANSITION-NEEDED 259 for some users. Strong mechanisms can progress partway through 260 negotiation prior to issuing the TRANSITION-NEEDED failure message 261 in order to avoid this problem. 263 An attacker might probe for users using the POP3 USER command to 264 probe for AUTH-TOO-WEAK or ENCRYPT-NEEDED. Server implementations 265 could use these error codes for unknown users to defeat this 266 attack. Delaying the error until after the PASS command is 267 supplied would unnecessarily reveal a user's password and thus 268 would be a far more serious problem than probing for users. 270 An active attacker can always cause a down-negotiation to the 271 weakest authentication mechanism or cipher suite available. For 272 this reason, implementations need to be configurable to refuse weak 273 mechanisms or cipher suites. 275 9. References 277 [ABNF] Crocker, "Augmented BNF for Syntax Specifications: ABNF", work 278 in progress. 280 [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text 281 Messages", RFC 822, University of Delaware, August 1982. 283 285 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", 286 RFC 2060, University of Washington, December 1996. 288 290 [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731, 291 Carnegie-Mellon University, December 1994. 293 295 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement 296 Levels", RFC 2119, Harvard University, March 1997. 298 300 [PGP-MIME] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", 301 RFC 2015, The Aerospace Corporation, October 1996. 303 305 [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 306 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 308 310 [POP3EXT] Newman, "POP3 Extension Mechanism and Error Codes", Work in 311 progress. 313 [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie 314 Mellon, December 1994. 316 318 [SASL] Myers, "Simple Authentication and Security Layer (SASL)", RFC 319 2222, Netscape Communications, October 1997. 321 323 [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in progress. 325 10. Full Copyright Statement 327 Copyright (C) The Internet Society 1997. All Rights Reserved. 329 This document and translations of it may be copied and furnished to 330 others, and derivative works that comment on or otherwise explain 331 it or assist in its implmentation may be prepared, copied, 332 published and distributed, in whole or in part, without restriction 333 of any kind, provided that the above copyright notice and this 334 paragraph are included on all such copies and derivative works. 335 However, this document itself may not be modified in any way, such 336 as by removing the copyright notice or references to the Internet 337 Society or other Internet organizations, except as needed for the 338 purpose of developing Internet standards in which case the 339 procedures for copyrights defined in the Internet Standards process 340 must be followed, or as required to translate it into languages 341 other than English. 343 The limited permissions granted above are perpetual and will not be 344 revoked by the Internet Society or its successors or assigns. 346 This document and the information contained herein is provided on 347 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 348 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 349 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 350 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 351 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 353 11. Author's Address 355 Chris Newman 356 Innosoft International, Inc. 357 1050 Lakes Drive 358 West Covina, CA 91790 USA 360 Email: chris.newman@innosoft.com