[873] in Kerberos_V5_Development
Re: Proposed Kerberos V5 Password Changing Algorithm
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Mon Feb 27 14:00:23 1995
Date: Mon, 27 Feb 1995 14:00:08 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: eichin@MIT.EDU
Cc: tytso@MIT.EDU, rsalz@osf.org, krbdev@MIT.EDU
In-Reply-To: "[869] in Kerberos_V5_Development"
Date: Fri, 24 Feb 95 16:51:47 -0500
From: eichin@MIT.EDU
Some other suggestions:
1) throw out the MOTD service. There are a whole host of
issues with doing that "right" and you've ignored all of them.
It is useful to be able to allow the system administrator to set a
message which is displayed to the user before the password prompt. Yes,
this service can get arbitrarily complex if you care about only
displaying the message once, etc. But if you don't care about that, a
simple motd service is still useful.
For example, it might display the current password policy in effect for
that user, say.
... Also, this way the protocol is a simple bang-bang interchange.
2) permit or recommend UDP implementation as well (after all,
nothing in the protocol actually needs TCP, right?)
4) throw out the QUIT command and reply. All it seems to
provide is another opportunity for protocol failure (any time the
response "must" be a certain value brings up the question of "then why
transmit the value in the first place, and why check it if you do?")
If the protocol is a bang-bang interchange, then UDP might actually be
simpler (although you still have to worry about retransmission issues).
I deliberately wanted to the design to allow for its eventual extension
to be a full-featured Kerberos V5 administration protocol. That would
be part of the mandatory subset which would be proposed for
standardization at the IETF. But, it would be possible for the
implementation of the daemon to be extended to handle creating new
users, setting (other) user's passwords, creating srvtabs, etc.
3) don't mix length-strings and null-terminated-strings. I'd
recommend using *only* length-strings, to simplify allocating storage
and packet-size sanity checks.
I've haven't mixed length-strings and null-terminated strings.
Everything should be length strings --- in a few cases, some of the
length strings have an additional constraints that ASCII NULLs are
prohibited, to simply the implementation of the protocol, but everything
still has a length count.
5) throw out the argument counts -- the command code is enough
to make it clear how much is needed. If more arguments are needed in
the future, add new command codes.
The argument counts simplify the debugging functions; they don't need
knowledge of the structure of the argument counts, in that case. It's
also necessary so that the server can determine where the end of a
command packet is, in the case where the server hasn't implemented a
particular command --- so it doesn't know how many arguments it
nominally takes.
As far as command codes vs. actually named commands --- Using numbers to
indicate command codes is a bad idea, because there's a greater chance
of conflict when someone extends the protocol.
Didn't this happen already with the V4 admin server, where Cygnus had
used "7" to do something new and different, and thus you had trouble
integrating my new "get_srvtab" functionality, since it also used
command code "7"? I seem to remember your mentioning a problem along
these lines.
- Ted
