Internet Draft R. Gellens Document: draft-gellens-password-00.txt QUALCOMM Expires: August 2001 February 2001 Password-Changing Protocol Status of this Memo: This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at The list of Internet-Draft Shadow Directories can be accessed at . A version of this draft document is intended for submission to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. Copyright Notice Copyright (C) The Internet Society 2001. All Rights Reserved. Gellens Expires August 2001 [Page 1] Internet Draft Password-Changing Protocol February 2001 Table of Contents 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in this Document . . . . . . . . . . . . . . 2 3. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Password-Change Protocol . . . . . . . . . . . . . . . . . . 3 4.1. Response Codes . . . . . . . . . . . . . . . . . . . . . 3 4.1.1. Detail Codes . . . . . . . . . . . . . . . . . . . . 3 4.2. Server Greeting . . . . . . . . . . . . . . . . . . . . 4 4.3. STARTTLS Command . . . . . . . . . . . . . . . . . . . . 4 4.4. PASSWORD Command . . . . . . . . . . . . . . . . . . . . 5 4.5. QUIT Command . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Appendix A: poppassd . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 7 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . 7 1. Abstract A number of existing clients and servers currently support the "poppassd" protocol for changing passwords. This protocol is extremely insecure, as it transmits the user name, current and new passwords in clear text. It also has more round-trips than needed, and lacks an extension mechanism. In addition, it is not possible to specify for which service(s) the password is to be changed. The protocol also traditionally usurps port 106, which is actually assigned for a different purpose. This document proposes a replacement protocol for password changing which is easy to implement on both client and server, and avoids the above problems. 2. Conventions Used in this Document The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. In examples, lines beginning with "C:" and "S:" represent text sent by the client and server, respectively. Any line wrapping is done for editorial clarity only. Commands and responses may be sent in any case. Use of upper case is for editorial clarity only. Gellens Expires August 2001 [Page 2] Internet Draft Password-Changing Protocol February 2001 3. Comments Because the existing "poppassd" started as an adjunct to POP servers and clients, public comments can be sent to the IETF POP Extensions mailing list, . To subscribe, send a message to with the word SUBSCRIBE as the body. Depending on how you are reading this, you may be able to simply click here: . Private comments should be sent to the author. 4. Password-Change Protocol Summary: The server listens on port XXX. In response to a client opening a connection, the server sends a greeting which lists the supported capabilities, including privacy mechanisms. The client initiates a security layer. If successful, the client sends a request which includes the service(s), authorization identity (the identity who password is to be changed), authentication identity (the identity performing the change), current authentication password, and new password. The server responds with a status. The client requests that the connection be closed. The server responds, and closes the connection. 4.1. Response Codes Response codes are OK, NO, or BAD, optionally followed by a hierarchical detail code, which may optionally include a URL for more information. All codes may be followed by a quoted string. This string may be useful for debugging or logging. OK indicates the command succeeded. Normally, a detail code is not used. NO indicates the command failed. Normally a detail code is sent, which may be followed by a URL. The detail code allows the client to display a meaningful error to the user, possibly translated into a display language. The URL allows site policy to be explained. BAD indicates the command is invalid or malformed. Normally a detail code is sent. 4.1.1. Detail Codes Detail codes consist of a hierarchical series of slash-separated words, each providing more detail. Detail codes MUST be registered with IANA. See section 5, IANA Considerations for more information. The entire detail code is enclosed in square brackets ("[" and "]"). Gellens Expires August 2001 [Page 3] Internet Draft Password-Changing Protocol February 2001 An optional URL, enclosed in angle brackets ("<" and ">") MAY follow the final detail and precede the close square bracket. An [ABNF] description of detail codes: detail-code = "[" detail *( "/" detail ) [ url-text ] "]" detail = 1*ALPHA url-text = "<" url ">" ; url defined in [BASIC-URL] Examples: NO [POLICY] NO [POLICY ] NO [PRIVACY] "Negotiate TLS and reissue command" Initial detail codes: POLICY The new password was rejected for site-policy reasons. PRIVACY A security (encryption) layer must be in force before the command can be issued. 4.2. Server Greeting The server greeting is OK or NO. If NO, the connection is then closed. If OK, the server announces its capabilities. Capabilities are sent as a hierarchical, parenthesized, space-separated list. Capabilities MUST be registered with IANA. See 5, IANA Considerations for more information. In ABNF: greeting = "NO" / "OK" [chatter] SP services SP capabilities chatter = SP <"> 1*CHAR <"> services = SERVICES service-list service-list = "(" service *( SP service ) ")" service = 1*ALPHA capabilities = "CAPABILITIES" capa-list capa-list = "(" [ capa-item *( SP capa-item ) ] ")" capa-item = 1*ALPHA [ capa-param ] capa-param = 1*ALPHA [ *( SP 1*ALPHA ) ] Examples: OK "password changer ready" SERVICES(MAIL) CAPABILITIES(TLS) OK SERVICES(MAIL WEB) CAPABILITIES(TLS) Gellens Expires August 2001 [Page 4] Internet Draft Password-Changing Protocol February 2001 4.3. STARTTLS Command The STARTTLS command starts a TLS negotiation. The client includes the name of the server in the STARTTLS command. This allows one physical server to host multiple virtual domains without needing extra IP addresses. A TLS negotiation begins immediately after the CRLF at end of the OK response from the server. An ERR response MAY result if a security layer is already active. Once a client issues the STARTTLS command, it MUST NOT issue and further commands until a server response is seen and the TLS negotiation is complete. In ABNF: starttls = "STARTTLS" server-name server-name = 1*CHAR Example: C: STARTTLS mail.example.org S: OK 4.4. PASSWORD Command The PASSWORD command requests that a password be changed. A client MAY send multiple requests (for example, to change the passwords for several accounts). request = "PASSWORD" SP services SP authorization NULL authentication NULL current-pw new-pw services = "(" 1*ALPHA *( SP 1*ALPHA ) ")" authorization = 1*CHAR ; user performing the action authentication = 0*CHAR ; change this password current-pw = 1*CHAR ; current password for authorization new-pw = 1*CHAR ; requested new password Examples: C: PASSWORD (mail) fred00dumb0dumber 00 0 S: NO [POLICY] "New password fails multiple tests" C: PASSWORD (mail) maida00S0leBurY770I11iaD75 00 0 S: OK "mail password for maida updated" 4.5. QUIT Command Gellens Expires August 2001 [Page 5] Internet Draft Password-Changing Protocol February 2001 The QUIT command inicates that the client has no further requests. The server responds with an OK, and then closes the connection. The client closes the connection after receiving the OK response. 5. IANA Considerations IANA is requested to maintain a registry of password-change service names and response detail codes. These registries can be added to on a first-come, first-served basis, however, the item to be registered MUST be defined in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. (This is the "Specification Required" policy described in [IANA]). 6. Appendix A: poppassd For historical interest, the "poppassd" protocol is described below: C: S: 200 poppassd (version 1.1) ready. C: USER fred S: 300 send password C: PASS stupid S: 200 Hello, fred. C: NEWPASS still-stupid S: 200 Password changed for fred C: QUIT S: Goodby. C: S: 200 poppassd (version 1.1) ready. C: USER fred S: 300 send password C: PASS stupid S: 500 Incorrect login. C: QUIT S: Goodby. 7. References Gellens Expires August 2001 [Page 6] Internet Draft Password-Changing Protocol February 2001 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., November 1997. [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994. 8. Security Considerations The security implications of a password-changing protocol are obvious and serious. Interception of a request exposes a password which the user may feel is secure (after all, it was just changed). Clients and servers which support the current insecure "popassd" protocol SHOULD implement this replacement, and SHOULD use it instead. 9. Acknowledgments Thanks to Chris Newman for his suggestions. 10. Author's Address Randall Gellens +1 858 651 5115 QUALCOMM Incorporated randy@qualcomm.com 5775 Morehouse Drive San Diego, CA 92121-2779 U.S.A. 11. Full Copyright Statement Copyright (C) The Internet Society 2001. 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 Gellens Expires August 2001 [Page 7] Internet Draft Password-Changing Protocol February 2001 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. Gellens Expires August 2001 [Page 8]