Internet DRAFT - draft-gellens-password
draft-gellens-password
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
<http://www.ietf.org/ietf/1id-abstracts.txt>
The list of Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
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, <ietf-pop3ext@imc.org>. To subscribe, send a message
to <mailto:ietf-pop3ext-request@imc.org> with the word SUBSCRIBE as
the body. Depending on how you are reading this, you may be able to
simply click here:
<mailto:ietf-pop3ext-request@imc.org?body=subscribe>.
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 <http://int.example.org/policies/passwords#length>]
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: <open connection to port 106>
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: <open connection to port 106>
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. <ftp://ftp.isi.edu/in-notes/rfc2234.txt>
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997.
<ftp://ftp.isi.edu/in-notes/rfc2119.txt>
[BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource
Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of
Minnesota, December 1994. <ftp://ftp.isi.edu/in-notes/rfc1738.txt>
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]
