idnits 2.17.1 draft-newman-auth-resp-00.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-16) 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 Introduction 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. ** The abstract seems to contain references ([ACAP], [POP3], [ESMTP-ERR], [POPEXT], [IMAP4], [SMTP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1893, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1939, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2244, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC821, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2060, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC821, updated by this document, for RFC5378 checks: 1982-08-01) -- 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 (July 1998) is 9407 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: 'ESMTP-ERR' is mentioned on line 41, but not defined == Missing Reference: 'ESMTP-CODES' is mentioned on line 230, but not defined == Missing Reference: 'SMTP-AUTH' is mentioned on line 307, but not defined == Unused Reference: 'CRAM-MD5' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'HTTP' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'POP-AUTH' is defined on line 420, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 1734 (ref. 'POP-AUTH') (Obsoleted by RFC 5034) -- Possible downref: Non-RFC (?) normative reference: ref. 'POPEXT' ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: Authentication Responses Innosoft 4 Document: draft-newman-auth-resp-00.txt July 1998 5 Updates: RFC 821, 1893, 1939, 2060, 2244 Expires in six months 7 Authentication Responses for Protocols (SMTP, IMAP, POP, etc) 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 27 West Coast). 29 Abstract 31 This memo assigns client authentication error codes for those 32 situations where a client may take specific corrective action in 33 the face of a failed authentication attempt. Some of these codes 34 are used by one strategy to transition users away from unencrypted 35 clear text passwords. 37 A number of important security considerations related to 38 authentication errors are also discussed. 40 This memo assigns SMTP error codes [SMTP], ESMTP error codes 41 [ESMTP-ERR], IMAP response codes [IMAP4], POP3 [POP3] extension 42 codes [POPEXT], and ACAP [ACAP] response codes. 44 1. Conventions Used in this Memo 46 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 47 in this document are to be interpreted as defined in "Key words for 48 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 50 1.1. Terminology Used in the Memo 52 Authentication Credentials 53 The information the client sends to the server to prove its 54 identity to the server. 56 Authentication Verifier 57 A piece of per-user data stored on a server which is used to 58 verify if an authentication exchange for a given user includes 59 valid authentication credentials. 61 Passphrase 62 The term "passphrase" is used rather than "password" to 63 discourage the use of simple single-word passphrases. 65 2. Concealing Users on the System 67 Before discussing specific error codes, it is important to note 68 that an active attacker who is aware of the userids of people on 69 the system is more dangerous than an active attacker with no 70 information. This concern is pervasive when discussing 71 authentication error codes, because it is very easy to reveal the 72 existance of a user with an incautious authentication error system. 74 However, there may be cases where it is more important to give the 75 client good information so it can take corrective action, than it 76 is to conceal users. For example, help desk costs necessary for 77 users who see a generic "Authentication Failed" error at one site 78 might outweigh the risk of revealing system userids to an active 79 attacker. 81 Every server which provides client authentication SHOULD have a 82 configuration setting where the validity of a user is not revealed 83 by a failed authentication attempt. In particular, the 84 non-existance of a user is treated identically to a bad passphrase, 85 an authentication mechanism deemed too weak, or a missing 86 authentication verifier, both in the text of the protocol and in 87 the speed of the server response. 89 3. An Authentication Transition System 91 While there is a strong desire to stop sending unencrypted clear 92 text passphrases, system administrators of existing systems often 93 are unable to do so unless it is nearly painless for the users. A 94 number of Internet protocols (e.g., HTTP, POP, ACAP, IMAP, SNMP, 95 PPP) now have standards track challenge-response authentication 96 mechanisms based on cryptographic hash functions. However, the 97 authentication verifier for these mechanisms is either the user's 98 passphrase itself or something derived from it in a special way. 100 Unfortunately, most sites with existing users have authentication 101 verifiers that are an incompatible one-way function of the user's 102 passphrase. Thus a new mechanism normally can not be deployed 103 without forcing users to set new passphrases on the system. So 104 even if a user were to set his POP client to use APOP [POP3], the 105 authentication would fail until the appropriate server verifier was 106 initialized. 108 A site which is more concerned with ending the use of unencrypted 109 clear text passphrases than with revealing users to an active 110 attacker can enable authentication transitioning. When a client 111 attempts to use APOP, but the verifier is not initialized, then the 112 server returns a response code indicating that a "transition is 113 needed." The client then attempts authentication with a clear text 114 passphrase one last time (with user confirmation) to force a 115 transition. After this, both the client and the server can flag 116 the user as transitioned and cease using unencrypted clear text 117 passphrases. 119 Note that a man-in-the-middle attacker could cause a client 120 authentication to fail with this specific error code in an attempt 121 to trick the client into using an unencrypted clear text 122 passphrase. A client can prevent this attack by negotiating a 123 full-strength encryption layer prior to using a clear text 124 passphrase for the transition, or mitigate the attack either by 125 getting explicit user permission for the transition or by saving a 126 flag after a successful strong authentication and refusing to 127 transition again. 129 4. Authentication Response Codes 131 This section identifies a number of authentication success and 132 error conditions where a client MAY take a specific action. For 133 each condition, a response code suitable for ACAP, IMAP or POP is 134 defined, a regular SMTP 3-digit error code, an enhanced SMTP error 135 code [ESMTP-CODES], and in some cases an FTP response codes from 137 [FTP-SEC] is included for completeness. 139 Some of the response codes are already defined in other 140 specifications and are included here for completeness, a reference 141 is included for already defined response codes. 143 Successful Authentication 145 ACAP, IMAP, POP: Generic "OK" response suffices 146 SMTP: 234 [SMTP-AUTH] 147 Enhanced SMTP: 2.7.0 148 FTP: multiple, see [FTP] and [FTP-SEC] for details 150 This indicates that the security exchange was successful. 152 Security Considerations: May not indicate client or server is 153 authenticated. 155 Successful Authentication with Data 157 ACAP: SASL base64data [ACAP] 158 IMAP, POP: N/A 159 SMTP: N/A 160 Enhanced SMTP: N/A 161 FTP: 235 [ADAT=base64data] [FTP-SEC] 163 This is used when the server has successfully authenticated 164 the client, but includes optional data in the response which 165 the client may use to mutually authenticate the server. 166 Protocols without such a response have an extra round-trip 167 when the server provides mutual authentication data as 168 described in SASL [SASL]. 170 Security Considerations: Integrity protection is not possible 171 if this information ignored by the client. 173 Temporary Authentication Failure 175 ACAP, IMAP, POP: TRYLATER [ACAP] 176 SMTP: 454 [SMTP-AUTH] 177 Enhanced SMTP: 4.7.0 178 FTP: 431 [FTP-SEC] 180 This occurs when there is a temporary failure during 181 authentication. It indicates some resource necessary to 182 authenticate is unavailable at the present time. 184 Security Considerations: May reveal information about users on 185 a system with multiple authentication sources where an earlier 186 one is local and a later one is remote. 188 Invalid Authentication Mechanism 190 ACAP, IMAP, POP: The generic BAD or -ERR response suffices 191 SMTP: 504 [SMTP, SMTP-AUTH] 192 Enhanced SMTP: 5.5.4 [ESMTP-CODES] 193 FTP: 504 [FTP, FTP-SEC] 195 This error code occurs when the client attempts to use an 196 authentication mechanism which the server does not implement. 198 Security Considerations: An active attacker could issue this 199 error code to attempt to get the client to try a weaker 200 mechanism and reveal more information. Clients SHOULD be 201 configurable to fail or get user permission if the only 202 remaining mechanisms are weak. 204 Authentication Failed (Bad user name or passphrase) 206 ACAP, IMAP, POP: The generic NO or -ERR response suffices 207 SMTP: 535 [SMTP-AUTH] 208 Enhanced SMTP: 5.7.8 209 FTP: 530 [FTP] 211 This occurs when an invalid user name is used, or the 212 passphrase or other authentication credentials are incorrect. 213 It is also the preferred error code for any non-syntax 214 failures which do not have a specific error code here. It is 215 quite reasonable for a server to return only success error 216 codes, or this error code. 218 Security Considerations: It is important not to distinguish 219 between "unknown user" and "bad passphrase" to conceal users. 220 It is important to supply a consistant delay when this error 221 code occurs to prevent fast password searches. A server MAY 222 unilaterally close the connection after a specific number of 223 failed authentication attempts to make password searches even 224 harder. 226 Authenticate Exchange Cancelled 228 ACAP, IMAP, POP: The generic BAD or -ERR response suffices 229 SMTP: 501 [SMTP-AUTH] 230 Enhanced SMTP: 5.7.0 [ESMTP-CODES] 231 FTP: not defined 233 This occurs when the client cancels a multiple-round-trip 234 authenticate exchange in the middle. SASL profiles are 235 required to document how the client cancels the exchange. 237 Security Considerations: none 239 Authentication Mechanism Too Weak 241 ACAP, IMAP, POP: AUTH-TOO-WEAK [ACAP] 242 SMTP: 522 [SMTP-AUTH] 243 Enhanced SMTP: 5.7.9 244 FTP: 534 [FTP-SEC] 246 Some currently deployed clients are staticly configured to use 247 only clear text passphrases by default, but can be configured 248 to support a stronger mechanism. This error code provides a 249 way to tell those clients that they are no longer permitted to 250 use a weak mechanism, such as clear text passphrases, and must 251 try something stronger. It may be particularly useful during 252 a transition period where a weaker mechanism is available to 253 un-transitioned users and a stronger mechanism is required for 254 transitioned users. 256 Security Considerations: Reveals information about the users 257 on the system, but provides ability to force clients to 258 upgrade their authentication. 260 Encryption Needed 262 ACAP, IMAP, POP: ENCRYPT-NEEDED [ACAP] 263 SMTP: 523 [SMTP-AUTH] 264 Enhanced SMTP: 5.7.10 265 FTP: not defined 267 This indicates that external strong privacy layer is needed in 268 order to use the requested authentication mechanism. This is 269 primarily intended for use with clear text authentication 270 mechanisms. A client which receives this may activate a 271 security layer such as TLS prior to authenticating, or attempt 272 to use a stronger mechanism. Note that code this does reveal 273 the existance of users on the system to an active attacker but 274 that is mitigated by the ability to force users to activate a 275 privacy layer. 277 Security Considerations: If this is applied regardless of the 278 user name supplied, this can improve site security. If this 279 is applied on a per-user basis, it can reveal information 280 about users on the system. 282 Expired Passphrase 284 ACAP, IMAP, POP: EXPIRED-PASS 285 SMTP: 524 286 Enhanced SMTP: 5.7.11 287 FTP: not defined 289 This indicates the user's passphrase or passphrase has expired 290 and needs to be changed. Many sites have a policy which 291 forbids a passphrase or passphrase from being used too long. 292 These sites will set a time period after which passphrases 293 must be changed. Some sites also pre-expire passphrases set 294 by a system administrator, such that a user must change their 295 passphrase prior to using their account. A client which 296 receives this error code can treat it as a user request to 297 change her passphrase. 299 Security Considerations: The server should verify that the 300 correct old authentication credentials were provided prior to 301 issuing this error, otherwise it would reveal information 302 about users on the system. 304 Transition Needed 306 ACAP, IMAP, POP: TRANSITION-NEEDED [ACAP] 307 SMTP: 422 [SMTP-AUTH] 308 Enhanced SMTP: 4.7.12 309 FTP: not defined 311 This occurs after a client attempts to authenticate using a 312 mechanism other than clear text. It indicates that the server 313 has an entry for the specified user in a legacy authentication 314 database but does not yet have an authentication verifier 315 necessary to offer the requested mechanism. A client which 316 receives this error code may do a one-time login using a clear 317 text login after asking the user for permission to activate 318 the transition. 320 Security Considerations: If clear text passwords are used to 321 transition, a strong privacy layer SHOULD be used. This error 322 reveals the existance of users to active attackers, but it 323 also provides an effective method to transition away from 324 using clear text passphrases without forcing users to change 325 their passphrases. 327 User Account Disabled 329 ACAP, IMAP, POP: DISABLED 330 SMTP: 525 331 Enhanced SMTP: 5.7.13 332 FTP: not defined 334 Sometimes a system administrator will have to disable a user's 335 account (e.g., due to lack of payment, abuse, evidence of a 336 break-in attempt, etc). This error code occurs after a 337 successful authentication to a disabled account. This informs 338 the client that the failure is permanent until the user 339 contacts their system administrator to get the account re- 340 enabled. It differs from a generic authentication failure 341 where the client's best option is to present the passphrase 342 entry dialog in case the user simply mistyped their 343 passphrase. 345 Security Considerations: Same as for EXPIRED-PASS above. 347 5. Gradual Transition on PLAIN Example 349 Here is a sample transition exchange between an IMAP client and 350 server. In this example, "C:" and "S:" indicate lines sent by the 351 client and server respectively. If such lines are wrapped without 352 a new "C:" or "S:" label, then the wrapping is for editorial 353 clarity and is not part of the command. 355 Note that this example uses the IMAP profile [IMAP4] of SASL 356 [SASL]. The base64 encoding of challenges and responses, as well 357 as the "+ " preceding the responses are part of the IMAP4 profile, 358 not part of SASL itself. Newer profiles of SASL will include the 359 initial client PLAIN message with the AUTHENTICATE command itself 360 so the extra round trip below (the server response with an empty "+ 361 ") can be eliminated. 363 In this example, the user's authentication identifier is "tim", his 364 authorization identifier is the same, and his passphrase is 365 "tanstaaftanstaaf". 367 S: * OK IMAP4 server ready 368 C: A001 CAPABILITY 369 S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=PLAIN 370 S: A001 OK done 371 C: A002 AUTHENTICATE CRAM-MD5 372 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ 373 C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw 374 S: A002 NO [TRANSITION-NEEDED] You can't login securely until 375 you've changed your passphrase on the server 376 377 C: A003 AUTHENTICATE PLAIN 378 S: + 379 C: AHRpbQB0YW5zdGFhZnRhbnN0YWFm 380 S: A003 OK You can now login securely in the future. 381 C: A004 SELECT INBOX 382 ... 384 6. Security Considerations 386 Security considerations are discussed throughout this document, and 387 in sections 2-4 in some detail. This memo focuses on two major 388 security concerns: network transmission of unencrypted clear text 389 passphrases, and revealing the existance of users on the system to 390 an attacker. It suggests one way to remedy the former at the 391 short-term expense of the latter weakness. 393 7. References 395 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 396 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 398 [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension 399 for Simple Challenge/Response", RFC 2195, MCI, September 1997. 401 [FTP] Postel, J., Reynolds, J., "FILE TRANSFER PROTOCOL (FTP)", RFC 402 959, ISI, October 1985. 404 [FTP-SEC] Horowitz, M., Lunt, S., "FTP Security Extensions", RFC 405 2228, Cygnus Solutions, Bellcore, October 1997. 407 [HTTP] Fielding, Gettys, Mogul, Frystyk, Berners-Lee, "Hypertext 408 Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, DEC, MIT/LCS, 409 January 1997. 411 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 412 4rev1", RFC 2060, University of Washington, December 1996. 414 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 415 Requirement Levels", RFC 2119, Harvard University, March 1997. 417 [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 418 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 420 [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie 421 Mellon, December 1994. 423 [POPEXT] Gellens, Newman, Lundblade "POP3 Extension Mechanism", 424 Work in progress. 426 [SASL] Myers, "Simple Authentication and Security Layer (SASL)", 427 RFC 2222, Netscape Communications, October 1997. 429 [SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821, 430 Information Sciences Institute, August 1982. 432 9. Acknowledgements 434 The following people provided helpful feedback on this document: 436 Ned Freed, Steve Hole, John Myers, Larry Osterman 438 10. Author's Address 440 Chris Newman 441 Innosoft International, Inc. 442 1050 Lakes Drive 443 West Covina, CA 91790 USA 445 Email: chris.newman@innosoft.com