Request for Comments: 3206 Category: Standards Track February 2002

Similar documents
Category: Standards Track August POP URL Scheme. Status of this Memo

Category: Standards Track September 2003

Network Working Group Request for Comments: 2342 Category: Standards Track Innosoft May 1998

Category: Standards Track August 2002

Category: Standards Track January 1999

Network Working Group Request for Comments: IBM L. Masinter AT&T December 1999

Network Working Group. Category: Standards Track February SIEVE Filtering: Spamtest and VirusTest Extensions

Category: Standards Track November Registration of Charset and Languages Media Features Tags. Status of this Memo

Category: Standards Track July The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism

Network Working Group Request for Comments: Category: Standards Track April 2001

Request for Comments: 2476 Category: Standards Track MCI December 1998

Category: Informational March Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration

Internet Engineering Task Force (IETF) Category: Experimental. February 2010

Category: Standards Track December 2003

Request for Comments: February Mobile IP Vendor/Organization-Specific Extensions

Updates: 2710 September 2003 Category: Standards Track. Source Address Selection for the Multicast Listener Discovery (MLD) Protocol

Network Working Group Request for Comments: 3634 Category: Standards Track Comcast Cable J. Bevilacqua N. Davoust YAS Corporation December 2003

Network Working Group Request for Comments: 3397 Category: Standards Track Apple Computer, Inc. November 2002

Request for Comments: 2711 Category: Standards Track BBN October 1999

Network Working Group Request for Comments: Category: Experimental J. Postel ISI December 1998

Category: Standards Track A. Malis Ascend Communications, Inc. September Inverse Address Resolution Protocol. Status of this Memo

Request for Comments: 4393 Category: Standards Track March MIME Type Registrations for 3GPP2 Multimedia Files

Category: Standards Track August 2002

Network Working Group. Category: Standards Track December 2001

Request for Comments: 2493 Category: Standards Track January 1999

Updates: 2535 November 2003 Category: Standards Track

Request for Comments: 2976 Category: Standards Track October 2000

Network Working Group. November Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)

Request for Comments: 4315 December 2005 Obsoletes: 2359 Category: Standards Track. Internet Message Access Protocol (IMAP) - UIDPLUS extension

Request for Comments: 3306 Category: Standards Track Microsoft August 2002

Network Working Group Request for Comments: Category: Standards Track A. B. Roach dynamicsoft June 2002

Network Working Group Request for Comments: 3508 Category: Informational April H.323 Uniform Resource Locator (URL) Scheme Registration

Network Working Group. Updates: 1894 June 2000 Category: Standards Track

Request for Comments: 3401 Updates: 2276 October 2002 Obsoletes: 2915, 2168 Category: Informational

Category: Informational November 2000

Category: Standards Track October 2006

Network Working Group Request for Comments: Category: Best Current Practice January 2004

Request for Comments: 3192 Obsoletes: 2304 October 2001 Updates: 2846 Category: Standards Track

Network Working Group. Category: Standards Track September Telnet Encryption: DES3 64 bit Cipher Feedback

Category: Informational 1 April 2001

Using SRP for TLS Authentication

Network Working Group Request for Comments: 3408 Category: Standards Track November 2002

Request for Comments: 3548 July 2003 Category: Informational

Network Working Group Request for Comments: January IP Payload Compression Using ITU-T V.44 Packet Method

November VeriSign Registry Registrar Protocol (RRP) Version 2.0.0

Network Working Group. Ohio University C. Metz The Inner Net September 1998

Expires: February 25, 2004 August 27, Using the NETCONF Configuration Protocol over Secure Shell (SSH) draft-wasserman-netconf-over-ssh-00.

Network Working Group. Category: Standards Track January 1999 Updates: 2284, 1994, PPP LCP Internationalization Configuration Option

Network Working Group Request for Comments: 3137 Category: Informational Cisco Systems A. Zinin Nexsi Systems D. McPherson Amber Networks June 2001

September Copyright (C) The Internet Society (2000). All Rights Reserved.

Category: Standards Track Cisco Systems, Inc January The Secure Shell (SSH) Session Channel Break Extension

Network Working Group. Category: Standards Track NIST November 1998

Network Working Group Request for Comments: DayDreamer March 1999

Request for Comments: 3601 Category: Standards Track September 2003

Isode Limited March 2008

Request for Comments: 2536 Category: Standards Track March DSA KEYs and SIGs in the Domain Name System (DNS)

Network Working Group Request for Comments: 2236 Updates: 1112 November 1997 Category: Standards Track

Request for Comments: 3172 BCP: 52 September 2001 Category: Best Current Practice

Request for Comments: 3578 Category: Standards Track dynamicsoft J. Peterson NeuStar L. Ong Ciena August 2003

Category: Standards Track June 1999

Request for Comments: A. Kullberg NetPlane Systems February 2003

Network Working Group. Category: Standards Track Cisco Systems May 2007

Network Working Group. Category: Standards Track Netscape Communications Corp. May 1999

Network Working Group Request for Comments: 2696 Category: Informational Microsoft T. Howes Netscape September 1999

Network Working Group. Obsoletes: draft-ietf-dhc-new-opt-msg-00.txt June 2000 Expires December 2000

Updates: 2409 May 2005 Category: Standards Track. Algorithms for Internet Key Exchange version 1 (IKEv1)

Network Working Group. Sun Microsystems October 2001

Multi-Server Based Namespace Data Management of Resource Namespace Service

Network Working Group. Category: Informational September 2000

Network Working Group Request for Comments: 5464 Category: Standards Track February 2009

Network Working Group. Category: Standards Track <draft-aboba-radius-iana-03.txt> 30 March 2003 Updates: RFC IANA Considerations for RADIUS

Category: Best Current Practice March 2000

See Also: 1201 January 1999 Category: Standards Track

Request for Comments: 3110 Obsoletes: 2537 May 2001 Category: Standards Track. RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)

Category: Standards Track October 2006

Network Working Group Request for Comments: 2921 Category: Informational September 2000

Network Working Group. Category: Informational January Unused Dynamic Host Configuration Protocol (DHCP) Option Codes

Network Working Group. Category: Standards Track July 2007

Request for Comments: 2771 Category: Informational February An Abstract API for Multicast Address Allocation

Request for Comments: Columbia U. November 2000

Network Working Group. Category: Informational Cisco Systems J. Brezak Microsoft February 2002

Request for Comments: 2304 Category: Standards Track March 1998

Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol

Request for Comments: 2393 Category: Standards Track Hi/fn R. Pereira TimeStep M. Thomas AltaVista Internet December 1998

Category: Standards Track Cisco Systems, Inc. March 2005

Request for Comments: 2303 Category: Standards Track March 1998

National Computerization Agency Category: Informational July 2004

Request for Comments: 2464 Obsoletes: 1972 December 1998 Category: Standards Track. Transmission of IPv6 Packets over Ethernet Networks

Request for Comments: 3007 Updates: 2535, 2136 November 2000 Obsoletes: 2137 Category: Standards Track. Secure Domain Name System (DNS) Dynamic Update

Network Working Group Request for Comments: 2866 Category: Informational June 2000 Obsoletes: 2139

Request for Comments: 3191 Obsoletes: 2303 October 2001 Updates: 2846 Category: Standards Track. Minimal GSTN address format in Internet Mail

Request for Comments: Intel M. Bokaemper Juniper Networks K. Chan Nortel Networks March 2003

Category: Standards Track December 2007

Network Working Group Request for Comments: 2595 Category: Standards Track June 1999

October Network News Transfer Protocol (NNTP) Extension for Streaming Feeds

Network Working Group. Cisco Systems Inc. October 2000

RFC 3173 IP Payload Compression Protocol September 2001

Network Working Group. February 2005

Category: Standards Track March Extensible Provisioning Protocol (EPP) Transport Over TCP

Category: Standards Track Cisco Systems, Inc. D. McPherson TCB K. Peirce Malibu Networks, Inc. November 2002

Transcription:

Network Working Group R. Gellens Request for Comments: 3206 QUALCOMM Category: Standards Track February 2002 Status of this Memo The SYS and AUTH POP Response Codes This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo proposes two response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP- CODE) is defined. Table of Contents 1. Introduction........................ 2 2. Conventions Used in this Document.............. 2 3. Background........................ 2 4. The SYS Response Code................... 3 5. The AUTH Response Code.................. 3 6. The AUTH-RESP-CODE Capability............... 4 7. IANA Considerations.................... 4 8. Security Considerations.................. 4 9. References........................ 5 10. Author s Address...................... 5 11. Full Copyright Statement................. 6 Gellens Standards Track [Page 1]

1. Introduction RFC 2449 [POP3-EXT] defined extended [POP3] response codes, to give clients more information about errors so clients can respond more appropriately. In addition to the mechanism, two initial response codes were defined (IN-USE and LOGIN-DELAY), in an attempt to differentiate between authentication failures related to user credentials, and other errors. In practice, these two response codes, while helpful, do not go far enough. This memo proposes two additional response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP-CODE) is defined. 2. Conventions Used in this Document 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 [KEYWORDS]. 3. Background RFC 2449 [POP3-EXT] introduced the IN-USE and LOGIN-DELAY response codes. The intent is to allow clients to clearly determine the underlying cause of a failure in order to respond. For example, clients need to know if the user should be asked for new credentials, or if the POP3 session should simply be tried again later. (Some deployed POP3 clients attempt to parse the text of authentication failure errors, looking for strings known to be issued by various servers which indicate the mailbox is locked.) IN-USE indicates that an exclusive lock could not be obtained for the user s mailbox, probably because another POP3 session is in progress. LOGIN-DELAY informs the client that the user has not waited long enough before authenticating again. However, there are other error conditions which do not require new credentials, some of which should be brought to the user s attention. Despite the IN-USE and LOGIN-DELAY responses, clients cannot be sure if any other error requires new user credentials. Gellens Standards Track [Page 2]

4. The SYS Response Code The SYS response code announces that a failure is due to a system error, as opposed to the user s credentials or an external condition. It is hierarchical, with two possible second-level codes: TEMP and PERM. (Case is not significant at any level of the hierarchy.) SYS/TEMP indicates a problem which is likely to be temporary in nature, and therefore there is no need to alarm the user, unless the failure persists. Examples might include a central resource which is currently locked or otherwise temporarily unavailable, insufficient free disk or memory, etc. SYS/PERM is used for problems which are unlikely to be resolved without intervention. It is appropriate to alert the user and suggest that the organization s support or assistance personnel be contacted. Examples include corrupted mailboxes, system configuration errors, etc. The SYS response code is valid with an -ERR response to any command. 5. The AUTH Response Code The AUTH response code informs the client that there is a problem with the user s credentials. This might be an incorrect password, an unknown user name, an expired account, an attempt to authenticate in violation of policy (such as from an invalid location or during an unauthorized time), or some other problem. The AUTH response code is valid with an -ERR response to any authentication command including AUTH, USER (see note), PASS, or APOP. Servers which include the AUTH response code with any authentication failure SHOULD support the CAPA command [POP3-EXT] and SHOULD include the AUTH-RESP-CODE capability in the CAPA response. AUTH-RESP-CODE assures the client that only errors with the AUTH code are caused by credential problems. NOTE: Returning the AUTH response code to the USER command reveals to the client that the specified user exists. It is strongly RECOMMENDED that the server not issue this response code to the USER command. Gellens Standards Track [Page 3]

6. The AUTH-RESP-CODE Capability CAPA tag: AUTH-RESP-CODE Arguments: none Added commands: none Standard commands affected: none Announced states / possible differences: both / no Commands valid in states: n/a Specification reference: this document Discussion: The AUTH-RESP-CODE capability indicates that the server includes the AUTH response code with any authentication error caused by a problem with the user s credentials. 7. IANA Considerations IANA has added the AUTH-RESP-CODE capability to the list of POP3 capabilities (established by RFC 2449 [POP3-EXT]). IANA has also added the SYS and AUTH response codes to the list of POP3 response codes (also established by RFC 2449 [POP3-EXT]). 8. Security Considerations Section 5, The AUTH Response Code, discusses the security issues related to use of the AUTH response code with the USER command. Gellens Standards Track [Page 4]

9. References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version 3", STD 53, RFC 1939, May 1996. [POP3-EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998. 10. Author s Address Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-2779 U.S.A. Phone: +1 858 651 5115 EMail: randy@qualcomm.com Gellens Standards Track [Page 5]

11. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Gellens Standards Track [Page 6]