[2450] in Kerberos_V5_Development
Re: Password changing protocols
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Fri Jul 18 13:42:17 1997
Date: Fri, 18 Jul 1997 13:41:17 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: Naomaru Itoi <itoi@eecs.umich.edu>, krbdev@MIT.EDU
In-Reply-To: Ken Hornstein's message of Wed, 16 Jul 1997 00:26:02 -0400,
<199707160425.AAA20710@ginger.cmf.nrl.navy.mil>
Here's the history, so that everyone understands what had happened in
the past.
A number of years ago, I recognized that we needed to standardize on
*some* password changing protocol. This was before OV had donated their
password changing protocol to us, and there were multiple commercial
implementations with different password changing protocols.
Hence, I developed a TCP-based password changing protocol and passed it
around to a number of different vendors to see if they would sign off on
it being a standard password changing protocol. At least one terminal
server vendor did accept it, and their hardware now support it. This is
the protocol which was implemented in the MIT Kerberos V5 1.0
distribution. Unfortunately, I got too busy to actually run it through
the IETF process and get the thing recognized as a standard.
Marc Horowitz at Cygnus then developed a simpler protocol (because he
thought the one I had done was too much work to implement) that was
based on UDP. (I actually think most of the problems with the TCP-based
protocol was an overly-complex implementation job by a consultant that I
had hired to do the implementation, but be that as it may.)
If I had my druthers, he wouldn't have developed the second protocol,
and simply used the first --- perhaps re-implementing it to avoid some
of the overly-general and therefore complex code in the first version of
the code. The last thing the Kerberos world needed was Yet Another
Password Changing Protocol (I think we're up to five or six now...).
However, that's not what happened, and it's been released as an
Internet-Draft.
Given that we now have this other competing proposal, which one should
we use? Marc's is a bit simpler, although it also isn't quite as
functional. Perhaps that's an argument to use his. On the other hand,
it does screw over the terminal server vendor who had implemented the
TCP-based password changing protocol in good faith. Which is more
important? It's a hard call to make.
It's ultimately not worth a lot of energy to fight over, though, so
since Marc seems so determined to have his protocol be blessed as the
standard, I suppose I'll let him "win" this one. If anyone has any
strong feelings about this, though, please let me know.
- Ted
