[877] in Kerberos_V5_Development
Re: Proposed Kerberos V5 Password Changing Algorithm
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Mon Feb 27 16:24:31 1995
Date: Mon, 27 Feb 1995 16:24:20 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: eichin@MIT.EDU
Cc: rsalz@osf.org, krbdev@MIT.EDU
In-Reply-To: eichin@MIT.EDU's message of Mon, 27 Feb 95 16:01:46 -0500,
<9502272101.AA00366@perdiem.cygnus.com>
Date: Mon, 27 Feb 95 16:01:46 -0500
From: eichin@MIT.EDU
I suppose it won't do much good to bring up internationalization
arguments in this context.
I8N is something you need to worry about for more than just the MOTD;
there are other places where text is being passed back to the client for
display to the user.
One of the ideas which I've been tossing around in my head is that the
client would send to the server a command packet with the command
"MIME". This would declare to the server that the client was capable
understanding MIME encoding, and so the server could then start sending
MIME encoded objects for the client to deal with, if the server
supported it.
Given that MIME is is turing equivalent, we would probably need to put
some restrictions on what sort of MIME types could be sent back to the
client, though. This needs more thought.
Now the only issue is that the server would need to figure out whether a
user should get the explanatory text sent back in Spanish, French,
English, or Japaneese. The server could simply keep a database of the
what language it should send back, but that's really user profile
information that has no business being stored on the KDC.
We could define a new command where the client sent back the locale
information to the server, but there's no standardized definition of
locale names. So this is something which I'm still thinking about.
Comments?
>> 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?)
This is a good point.
>> 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.
That's the way it was done in V4.
Admittedly there's not a lot in common, besides the fact that both
modify the database, and both need to be written with extreme paranoia,
but it certainly saves on the implementation effort. And, combining
both functions into a single program doesn't cause any serious problems.
Nor do I think it terribly complicates things, either.
My main reason for doing it is that I believe that a robust AND freely
available administration server will be most likely be available the
fastest if we adopt this course. This is something which I'd assume
would be of interest to Cygnus. :-)
>> 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.
I was planning to do the standard, "experimental or for extension"
commands must be prefixed with "X". It's merely an oversight that it
wasn't in the initial draft.
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.
Yes. It's only being used to provide retransmission (even sequencing is
going to be double checked by the sequence numbers in the KRB_PRIV
messages).
- Ted
