[855] in Kerberos_V5_Development
Proposed Kerberos V5 Password Changing Algorithm
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu Feb 16 17:39:08 1995
Date: Thu, 16 Feb 1995 17:31:28 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: Various Kerberos Software Vendors/Developers </dev/null@MIT.EDU>
Cc: krbdev@MIT.EDU
The following is being distributed to you for initial comment. This
list represents those people whom I know are working on Kerberos V5.
Many of you are planning to ship products based on Kerberos V5, and your
comments will be especially appreciated.
My plan is to post this to the Kerberos mailing list after this initial
comment period, and then to eventually promulgate this through the IETF
as an Internet standard.
The MIT reference implementation of Kerberos V5 will include an
implementation of the password changing client and server, and I hope
this will be quickly picked up by commercial versions of Kerberos as an
adjunct to whatever proprietary Kerberos administration protocols you
may be offering.
If you have any suggetions about how this protocol might be improved, or
changed so as to make it simpler for you to integrate into your Kerberos
V5 products, I would appreciate your sending mail to me. Please label
any future product information which you consider to be confidential,
and I will make best efforts to keep that information secure.
Thanks!!
- Ted
A Proposal for a Standardized
Kerberos Password Changing Protocol
**DRAFT** **DRAFT** **DRAFT**
by Theodore Ts'o
Februrary 15, 1994
Rationale
=========
Currently, the Kerberos administration server which is being shipped
with the Beta Kerberos V5 distributions from MIT has not been
functional and of sufficient quality for vendors to ship it in their
products. Hence, many vendors are creating and deploying proprietary
administration servers. In general, this is not a big problem ---
relatively few users are Kerberos administrators and thus the Kerberos
administration clients are used by relatively few users.
There is a big exception to this, however, which is the functionality of
a user being able to change his or her own password. Application
programs may want to include this functionality in their programs; it
would be desireable for there to be a standardized protocol for doing
this. Standardized Kerberos desktop management programs (such as
Cornell's Authman) would also benefit from a standardized protocol; this
way, they will do not need to implement many vendor-specific Kerberos
administration protocols. Similarily, at least one terminal server
vendor has come to expressing their concern that there was not a
standardized password changing protocol, since they wanted their product
to offer this functionality.
This protocol is designed to address these concerns.
Protocol Description
====================
The protocol used by the password changing protocol is intentionally
very simple. This is to encourage its widespread implementation, even
in cases where there are size constraints (i.e., in a terminal server).
The protocol will use a TCP stream connection, using port XXX.
The following encoding standards are used throughout.
Integers are sent as 4 byte objects, where the most significant byte
is sent first, and the least signifcant byte is sent last. (i.e.,
standard Internet network byte order.)
Protocol data units are sent across using the following encoding.
First, the size is sent as a 4 byte integer, followed by the PDU. The
PDU is either a Kerberos V5 KRB_AP_REQ, KRB_AP_REP, or KRB_PRIV
message. The initial exchange use the KRB_AP_REQ and KRB_AP_REP
message; all successive PDU's will be KRB_PRIV messages.
The KRB_PRIV messages must include the sequence number field --- the
client and server must fill in each successive PDU that it sends with a
monotonically increasing sequence number. The initial sequence number
in each direction are negotiated in the KRB_AP_REQ and KRB_AP_REP
messages.
The "command request" PDU
-------------------------
A common PDU used in the protocol is the "command request" PDU. A
command request PDU uses the following structure: First, the number of
arguments, sent across as an integer. The number of arguments MUST be
greater than zero. It is then followed by the arguments themselves,
which are encoded as an integer length followed by the value of the
argument.
The first argument is "command name", and it must be a NETASCII string
which may not contain an ASCII null. Command names are case
insentive. The other arguments (if any) are dependent on the command
specified by the first argument.
In other words:
Number of Arguments (integer, must be greater than zero)
Arg size 1 (integer)
Arg data 1 (octet string, command name)
...
Arg size N (integer)
Arg data N (octet string)
This structure is then encrypted inside the Kerberos V5 KRB_PRIV
message.
The "command reply" PDU
-----------------------
Another common PDU used in the protocol is the "command reply" PDU.
It is sent in reply to a "command request" PDU. The first portion of
the "command reply" PDU is common to all commands, and is required.
The rest of it is command specific.
It uses the following structure:
Error code (integer)
Number of reply components (integer, may be zero)
Arg size 1 (integer)
Arg data 1 (octet string)
...
Arg size N (integer)
Arg data N (octet string)
This structure is then encrypted inside the Kerberos V5 KRB_PRIV
message.
The error code may be one of the following values:
# Symbolic name Meaning
0 NO_ERROR No error
1 PW_UNACCEPT The password chosen by the user is unnacceptable.
2 BAD_PW The old password furnished by the user is not correct.
The error codes below 127, and above 256 are reserved for future
expansion. Local extensions of this protocol should use error codes
between 128 and 255.
The user text in the reply message is generally some sort of
explanatory text, which should be displayed to the user.
Connection Establishment
========================
When a connection is made the password changing client exchanges the
following PDU's:
Client Server
------ ------
KRB_AP_REQ ------->
<------- KRB_AP_REP
<------- MOTD
KRB_AP_REQ and KRB_AP_REP are the respective Kerberos V5 messages.
MOTD is an KRB_PRIV message which is sent by the server to the client.
It contains NETASCII text which is intended to be displayed to the
user. The message may be zero length (in which case nothing should be
displayed); the message may be user specific, or a general message, at
the descretion of the server.
Protocol Commands
==================
After the connection is established, the client may then send any
number of "command request" PDUs; after each command request PDU is
sent, the client should wait for a "command reply" PDU from the
server.
There are three commands defined in this standard: "QUIT", "CHECKPW",
and "CHANGEPW".
The quit command
----------------
The name of this command is "QUIT", and it takes no arguments. The
response to this command must be the error code "NO_ERROR". There may
be an optional reply component, which will consist of user text which
should be displayed to the user. After processing this command, the
server will terminate the connection.
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.
There may be an optional reply component which consists of user text
which should be displayed to the user. It will typically explain why
the password was unacceptable.
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.
There may be an optional reply component which consists of user text
which should be displayed to the user. It will typically explain why
the password was unacceptable.
