[876] in Kerberos_V5_Development
Re: Proposed Kerberos V5 Password Changing Algorithm
daemon@ATHENA.MIT.EDU (eichin@MIT.EDU)
Mon Feb 27 16:05:17 1995
Date: Mon, 27 Feb 95 16:01:46 -0500
To: tytso@MIT.EDU
Cc: tytso@MIT.EDU, rsalz@osf.org, krbdev@MIT.EDU
In-Reply-To: <9502271900.AA17573@dcl.MIT.EDU> (message from Theodore Ts'o on Mon, 27 Feb 1995 14:00:08 +0500)
From: eichin@MIT.EDU
[arg. Second try at this one. 1.1.94 crashes randomly.]
>> displaying the message once, etc. But if you don't care about that, a
>> simple motd service is still useful.
But we know from experience that if you repeat an unchanging message,
the user will rapidly become inured to it, and won't read it when it
finally *does* change.
I suppose it won't do much good to bring up internationalization
arguments in this context.
>> For example, it might display the current password policy in effect for
>> that user, say.
That sounds useful... but if you're talking about making this a
general maintenance protocol, it makes no sense at all. (Why would
someone fetching a srvtab care about their personal password policy?)
>> I deliberately wanted to the design to allow for its eventual extension
>> to be a full-featured Kerberos V5 administration protocol. That would
I'm not sure about the whole idea of putting together a simple
pseudo-rpc and then saying "ok, now lets build an entire admin
architecture on it." Allowing an entity to change its own password
should really be a simple operation, and really doesn't have much in
common with general administration.
I guess what I'm arguing for is that if you want a simple password
changing protocol, do it... do *just* that. This bit:
>> implementation of the daemon to be extended to handle creating new
>> users, setting (other) user's passwords, creating srvtabs, etc.
sounds like "since we've got this protocol anyway, lets stuff a whole
bunch of unrelated things into it." Given that we're making the
protocol deliberately simple (to make it easy to implement the
password changing function in terminal servers and the like) it isn't
clear that it needs to be general enough to do anything else...
>> I've haven't mixed length-strings and null-terminated strings.
>> Everything should be length strings --- in a few cases, some of the
Sorry about that, I misread the constraint on command name (it merely
says that it may not contain ASCII NUL, not that it is terminated by
one.)
>> The argument counts simplify the debugging functions; they don't need
True, and the overriding constraint here is simplicity of
implementation (though the debugging tools will presumably *always* be
up to date -- after all, you can just rebuild them...)
>> 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
This is, however, far more convincing :-) I thought that the length
was implied by the KRB_PRIV wrapping, but it isn't, that only encodes
a hash. So at least the server needs to know the length of the overall
packet, even if it doesn't need to be able to parse out the arguments
(since if it can't, it can't...)
>> 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.
It is only greater because the named commands are longer. In neither
case have you specified a range of "experimental" or "for extension"
codes, or at very least "reserved to MIT/IETF for standard protocol
extension" values. I could point out that com_err tables would handle
this function suitably for numeric codes, but that might be going
overboard.
>> 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
No, actually -- we grabbed 64 as "cygnus kadmin extension base" and
then allocated the first value in that range as the code for "delete
principal" exactly because I thought MIT might add other things. The
only reason we didn't have get_srvtab sooner is that I forgot to add
it :-) as it was one of the few things in 4p10 that wasn't already in
CNS.
>> If the protocol is a bang-bang interchange, then UDP might actually be
>> simpler (although you still have to worry about retransmission issues).
And length limits -- though now that the C-gateways are dead, the
limits are something like 8192 bytes, so that's not that big a deal.
More importantly is to note for future readers that the TCP stream is
not being used to provide *any* integrity.
_Mark_
