[895] in Kerberos_V5_Development
Request for an assigned TCP Port.
daemon@ATHENA.MIT.EDU (Clifford Neuman)
Fri Mar 17 17:26:08 1995
Date: Fri, 17 Mar 1995 14:26:54 -0800
From: Clifford Neuman <bcn@ISI.EDU>
To: tytso@MIT.EDU
Cc: krbdev@MIT.EDU
In-Reply-To: Theodore Ts'o's message of Sat, 11 Mar 1995 00:24:05 +0500 <9503110524.AA17778@dcl.MIT.EDU>
Ted,
Here are my comments on the password changing protocol. Some of these
comments may have already been made by others, or already fixed. I'm
not sure that this is based onthe latest versionof your document.
The status code may be one of the following values:
# Symbolic name Meaning
0 SUCCESS The command was executed without any errors
1 CMD_UNKNOWN Command not recognized
2 PW_UNACCEPT The password chosen by the user is unnacceptable.
3 BAD_PW The old password furnished by the user is not correct.
4 NOT_IN_TKT The ticket used to authenticate to the server
did not have the TKT_FLAG_INITIAL flag set.
5 CANT_CHANGE The server is not able to change the password
due to no fault of the user. (For
example, the database may be in
read-only mode for maintance reasons.)
6 LANG_NOT_SUPPORTED The requested language is not supported.
I'd add codes for the case where a password has been expired too long,
or is know to have been compromised, and policy requires the user to
contact an administrator to set a new password out of band (i.e. not
allowed to use the password changing protocol for some policy reason).
Do we want a separate code for this, or simply CANT_CHANGE. I think a
separate code. Can't change mighe mean try again later. This new
code should be accompanied by text to be sent back to the user.
Also, I assume that CMD_UNKNOWN is defined to be sent back whenever
the command is not recognized, whether and X- command, or an non X-
command that might at some point in the future be defined, but just
not in the version of the server one is communicating with.
The check password command
---------------------------
The name of this command is "CHECKPW", and it takes one argument,
which is a proposed password. The server will evaluate this password
according to its criteria and return either an NO_ERROR or PW_UNACCEPT
error code.
NO_ERROR is defined as SUCCESS above. It should be consistent.
The change password command
---------------------------
The name of this command is "CHANGEPW", and it takes two arguments. The
first argument is the old password, and the second password is the new
password. The response from this command will generally be one of the
following error codes: NO_ERROR, PW_UNACCEPT, BAD_PW, NOT_IN_TKT,
CANT_CHANGE.
This command changes the password of the Kerberos principal which the
client used to authenticate to the server. For security reasons, the
server should check to make sure that the ticket used to authenticate to
the server had the TKT_FLG_INITIAL flag set; if this flag is not set in
the ticket, then when the client attempts to use the "CHANGEPW" command,
the server should return the NOT_IN_TKT error.
There may be an optional reply component which consists of user text
which should be displayed to the user, explaining why the password was
unacceptable or why the user's password could not be changed.
Kerberos password changing servers MUST implement this command.
How about requiring the principal whose password is to be change to be
specified. Yes, it is redunant in the case that it is the same as the
principal that was authenticated. However, one might wnat to use this
as a poor mans kadmin too, no fancy stuff, just like the unix passwd
command when run by root allows chaning the password for any user. In
this case if run by an administrator principal, it should allow the same.
---------------
The Message of the Day command
------------------------------
The name of this command is "MOTD", and it takes zero or one additional
arguments. The optional argument is a magic token passed back from a
previous MOTD command. If this magic token is sent, the server MAY use
it to determine use it to determine what (if any) messages should be
displayed to the user.
Change the last sentence to "...if the message has changed and must be
returned to the client." Add a note that if it has not changed, and
no new messages is returned to the client, then the client must
display to the user the old information associated with that token.
Also, please define what happens in the event that there is no MOTD
now, but there was one in the past, for which the token was sent. How
do we define it as no longer existing. Personally, I'm for dropping
this magic token. It seems complicating of the protocol, and MOTD's
won't be so long that this is a major gain.
Finally, I'd like to see a statement that we want to encourage new
administration protocols to be fit into this framework, initially
using the X-VENDOR-command commands, and where there is comonality,
through future documents defining common administraton commands across
vendors which when agreed upon would then drop the X-VENDOR.
