idnits 2.17.1 draft-newman-tls-imappop-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 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. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (April 1998) is 9501 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) == Unused Reference: 'IMAP-AUTH' is defined on line 382, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** 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' ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 4 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, POP3 and ACAP Innosoft 4 Document: draft-newman-tls-imappop-04.txt April 1998 6 Using TLS with IMAP4, POP3 and ACAP 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 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 Introduction 30 The TLS protocol [TLS] (formerly known as SSL) provides a way to 31 secure a connection from tampering and eavesdropping. Obviously, 32 the option of using such security is desirable for IMAP [IMAP4], 33 POP [POP3] and ACAP [ACAP]. Although advanced SASL [SASL] 34 authentication mechanisms can provide a lightweight version of this 35 service, TLS is a full service security layer and is also useful in 36 combination with plain-text password logins and other simple 37 mechanisms as it doesn't require a site to upgrade its 38 authentication database. 40 This specification defines extensions to IMAP4, POP3 and ACAP which 41 activate TLS. This also defines a simple PLAIN SASL mechanism for 42 use underneath strong TLS encryption with ACAP or other protocols 43 lacking a plain-text login command. 45 1. Conventions Used in this Document 47 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 48 NOT", and "MAY" in this document are to be interpreted as described 49 in "Key words for use in RFCs to Indicate Requirement Levels" 50 [KEYWORDS]. 52 Formal syntax is defined using ABNF [ABNF]. 54 In examples, "C:" and "S:" indicate lines sent by the client and 55 server respectively. 57 2. Cipher Suite Requirements 59 This application profile of TLS follows the standard "Mandatory 60 Cipher Suites" requirement as documented in the TLS specification 61 [TLS]. Implementations MUST NOT assume any other cipher suites are 62 present. 64 3. IMAP4 STARTTLS extension 66 When the TLS extension is present in IMAP4, "STARTTLS" is listed as 67 a capability in response to the CAPABILITY command. This extension 68 adds a single command, "STARTTLS" to the IMAP4 protocol which is 69 used to begin a TLS negotiation. 71 3.1. STARTTLS Command 73 Arguments: none 75 Responses: no specific responses for this command 77 Result: OK - begin TLS negotiation 78 NO - security layer already active 79 BAD - command unknown or arguments invalid 81 A TLS negotiation begins immediately after the CRLF at the end of 82 the tagged OK response from the server. Once a client issues a 83 STARTTLS command, it MUST NOT issue further commands until a 84 server response is seen and the TLS negotiation is complete. 86 The STARTTLS command is only valid in non-authenticated state. 87 The server remains in non-authenticated state, even if client 88 credentials are supplied during the TLS negotiation. The SASL 89 [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS 90 client credentials are successfully exchanged, but servers 91 supporting the STARTTLS command are not required to support the 92 EXTERNAL mechanism. 94 Once TLS has been started, the client SHOULD discard cached 95 information about server capabilities and re-issue the CAPABILITY 96 command. This is necessary to protect against man-in-the-middle 97 attacks which alter the capabilities list prior to STARTTLS. The 98 server MAY advertise different capabilities after STARTTLS. 100 The formal syntax for IMAP4 is amended as follows: 102 command_any =/ "STARTTLS" 104 Example: C: a001 CAPABILITY 105 S: * CAPABILITY IMAP4rev1 STARTTLS 106 S: a001 OK CAPABILITY completed 107 C: a002 STARTTLS 108 S: a002 OK Begin TLS negotiation now 109 110 C: a003 CAPABILITY 111 S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL 112 S: a003 OK CAPABILITY completed 113 C: a004 LOGIN joe password 114 S: a004 OK LOGIN completed 116 4. POP3 STLS extension 118 The POP3 STLS extension adds the STLS command to POP3 servers. If 119 this is implemented, the POP3 extension mechanism [POP3EXT] MUST also 120 be implemented to avoid the need for client probing of multiple 121 commands. The capability name "STLS" indicates this command is 122 present. 124 STLS 126 Arguments: none 128 Restrictions: 129 Only permitted in AUTHORIZATION state. 131 Discussion: 132 A TLS negotiation begins immediately after the CRLF at the 133 end of the +OK response from the server. A -ERR response 134 MAY result if a security layer is already active. Once a 135 client issues a STLS command, it MUST NOT issue further 136 commands until a server response is seen and the TLS 137 negotiation is complete. 139 The STLS command is only permitted in AUTHORIZATION state 140 and the server remains in AUTHORIZATION state, even if 141 client credentials are supplied during the TLS negotiation. 142 The AUTH command [POP-AUTH] with the EXTERNAL mechanism 143 [SASL] MAY be used to authenticate once TLS client 144 credentials are successfully exchanged, but servers 145 supporting the STLS command are not required to support the 146 EXTERNAL mechanism. 148 Once TLS has been started, the client SHOULD discard cached 149 information about server capabilities and re-issue the CAPA 150 command. This is necessary to protect against 151 man-in-the-middle attacks which alter the capabilities list 152 prior to STLS. The server MAY advertise different 153 capabilities after STLS. 155 Possible Responses: 156 +OK -ERR 158 Examples: 159 C: STLS 160 S: +OK Begin TLS negotiation 161 162 ... 163 C: STLS 164 S: -ERR Security Layer already active 166 5. ACAP STARTTLS extension 168 When the TLS extension is present in ACAP, "STARTTLS" is listed as 169 a capability in the ACAP greeting. No arguments to this capability 170 are defined at this time. This extension adds a single command, 171 "STARTTLS" to the ACAP protocol which is used to begin a TLS 172 negotiation. 174 5.1. STARTTLS Command 176 Arguments: none 178 Responses: no specific responses for this command 180 Result: OK - begin TLS negotiation 181 NO - security layer already active 182 BAD - command unknown or arguments invalid 184 A TLS negotiation begins immediately after the CRLF at the end of 185 the tagged OK response from the server. Once a client issues a 186 STARTTLS command, it MUST NOT issue further commands until a 187 server response is seen and the TLS negotiation is complete. 189 The STARTTLS command is only valid in non-authenticated state. 190 The server remains in non-authenticated state, even if client 191 credentials are supplied during the TLS negotiation. The SASL 192 [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS 193 client credentials are successfully exchanged, but servers 194 supporting the STARTTLS command are not required to support the 195 EXTERNAL mechanism. 197 After the TLS layer is established, the server MUST re-issue an 198 untagged ACAP greeting. This is necessary to protect against 199 man-in-the-middle attacks which alter the capabilities list prior 200 to STARTTLS. The client SHOULD discard cached capability 201 information and replace it with the information from the new ACAP 202 greeting. The server MAY advertise different capabilities after 203 STARTTLS. 205 The formal syntax for ACAP is amended as follows: 207 command_any =/ "STARTTLS" 209 Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) 210 C: a002 STARTTLS 211 S: a002 OK "Begin TLS negotiation now" 212 213 S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") 215 6. PLAIN SASL mechanism 217 Plain-text passwords are simple, interoperate with almost all 218 existing operating system authentication databases, and are useful 219 for a smooth transition to a more secure password-based 220 authentication mechanism. The drawback is that they are 221 unacceptable for use unencrypted over the network. 223 This defines a PLAIN SASL mechanism for use with ACAP and future 224 protocols with no plain-text login command. This MUST NOT be 225 implemented unless TLS (or an equivalent security layer) is also 226 implemented. 228 The SASL [SASL] mechanism name is "PLAIN". 230 The mechanism consists of a single message from the client to the 231 server. The client sends the authorization identity (identity to 232 login as), followed by a US-ASCII NUL character, followed by the 233 authentication identity (identity whose password will be used), 234 followed by a US-ASCII NUL character, followed by the plain-text 235 password. The client may leave the authorization identity empty to 236 indicate that it is the same as the authentication identity. 238 The server will verify the authentication identity and password 239 with the system authentication database and verify that the 240 authentication credentials permit the client to login as the 241 authorization identity. If both steps succeed, the user is logged 242 in. 244 The server MAY also use the password to initialize any new 245 authentication database, such as one suitable for CRAM-MD5 246 [CRAM-MD5], ACAP's mandatory-to-implement authentication mechanism. 248 Non-US-ASCII characters are permitted as long as they are 249 represented in UTF-8 [UTF-8]. Use of non-visible characters or 250 characters which a user may be unable to enter on some keyboards is 251 discouraged. 253 The formal grammar for the client message using Augmented BNF 254 [ABNF] follows. 256 message = [authorize-id] NUL authenticate-id NUL password 258 authenticate-id = 1*UTF8-SAFE 259 ; MUST accept up to 255 octets 261 authorize-id = 1*UTF8-SAFE 262 ; MUST accept up to 255 octets 264 password = *UTF8-SAFE 265 ; MUST accept passwords up to 255 octets 267 NUL = %x00 269 UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / 270 UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 272 UTF8-1 = %x80-BF 274 UTF8-2 = %xC0-DF UTF8-1 276 UTF8-3 = %xE0-EF 2UTF8-1 278 UTF8-4 = %xF0-F7 3UTF8-1 280 UTF8-5 = %xF8-FB 4UTF8-1 281 UTF8-6 = %xFC-FD 5UTF8-1 283 Here is an example of how this might be used to initialize a 284 CRAM-MD5 authentication database for ACAP: 286 Example: S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") 287 (STARTTLS) 288 C: a001 AUTHENTICATE "CRAM-MD5" 289 S: + "<1896.697170952@postoffice.reston.mci.net>" 290 C: "tim b913a602c7eda7a495b4e6e7334d3890" 291 S: a001 NO (TRANSITION-NEEDED) 292 "Please change your password, or use TLS to login" 293 C: a002 STARTTLS 294 S: a002 OK "Begin TLS negotiation now" 295 296 C: a003 AUTHENTICATE "PLAIN" {21+} 297 C: timtanstaaftanstaaf 298 S: a003 OK AUTHENTICATE completed 300 Note: In this example, represents a single ASCII NUL octet. 302 Here is an example session where a client erroneously attempts to 303 use PLAIN prior to starting TLS: 305 Example: S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") 306 (STARTTLS) 307 C: a001 AUTHENTICATE "PLAIN" {21} 308 S: a001 NO (ENCRYPT-NEEDED) 309 "Can't use PLAIN without encryption" 311 7. imaps and pop3s ports 313 The common practice of using a separate port for a secure version 314 of each protocol has a number of disadvantages in the IMAP [IMAP4], 315 ACAP [ACAP] and POP [POP3] environment. Rather than using the best 316 security available, it means that clients have to be explicitly 317 configured to use the separate secure port or suffer the 318 performance loss of probing for active ports. For IMAP and ACAP, 319 this is even more serious as it would require a new URL scheme 320 which could only be resolved by TLS-enabled clients. 322 Separate "imaps" and "pop3s" ports were registered for use with 323 TLS. Use of these ports is discouraged in favor of the STARTTLS or 324 STLS command. 326 One of the arguments used in favor of the separate port technique 327 is that it simplifies configuration of firewalls which filter by IP 328 port. However, a quality server implementation running on the 329 standard port can be configured to require use of the STARTTLS 330 command or a suitably strong SASL mechanism for non-local 331 connections. This provides superior functionality as the client 332 need not be re-configured for use outside the firewall and faster 333 non-plain-text SASL mechanisms may be acceptable to many sites for 334 non-local connections. 336 8. Security Considerations 338 The mechanisms described in this document only apply to protecting 339 a single connection. Messages transferred over IMAP or POP3 are 340 still available to server administrators and usually subject to 341 eavesdropping, tampering and forgery when transmitted through SMTP 342 or NNTP. Protecting messages requires an object security mechanism 343 using MIME security multiparts [MIME-SEC]. 345 An active attacker can remove STARTTLS from the capability list. 346 In order to detect such an attack, clients SHOULD either warn the 347 user when session protection is not active, or be configurable to 348 refuse to proceed without an acceptable level of security. 350 An active attacker can always cause a down-negotiation to the 351 weakest authentication mechanism or cipher suite available. For 352 this reason, implementations need to be configurable to refuse weak 353 mechanisms or cipher suites. 355 Any protocol interactions prior to the TLS handshake are performed 356 in the clear and can be modified by an active attacker. For this 357 reason, clients SHOULD discard cached information about server 358 capabilities advertised prior to the start of the TLS handshake. 360 When the PLAIN mechanism is used with TLS, the server gains the 361 ability to impersonate the user to all services with the same 362 password. The PLAIN mechanism MUST NOT be used without an active 363 encryption layer using a key with an effective key length greater 364 than 56 bits, otherwise a passive attacker can gain the ability to 365 impersonate the user. 367 9. References 369 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 370 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 371 November 1997. 373 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 374 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 376 [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension 377 for Simple Challenge/Response", RFC 2195, MCI, September 1997. 379 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 380 4rev1", RFC 2060, University of Washington, December 1996. 382 [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731, 383 Carnegie-Mellon University, December 1994. 385 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 386 Requirement Levels", RFC 2119, Harvard University, March 1997. 388 [MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for 389 MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted 390 Information Systems, CyberCash, Innosoft International, October 391 1995. 393 [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 394 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 396 [POP3EXT] Gellens, Newman, Lundblade "POP3 Extension Mechanism", 397 Work in progress. 399 [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie 400 Mellon, December 1994. 402 [SASL] Myers, "Simple Authentication and Security Layer (SASL)", 403 RFC 2222, Netscape Communications, October 1997. 405 [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in 406 progress. 408 [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", 409 RFC 2279, Alis Technologies, January 1998. 411 10. Author's Address 413 Chris Newman 414 Innosoft International, Inc. 415 1050 Lakes Drive 416 West Covina, CA 91790 USA 418 Email: chris.newman@innosoft.com