[6091] in Kerberos
K5 recvauth
daemon@ATHENA.MIT.EDU (Howard Chu)
Wed Nov 1 16:15:48 1995
To: kerberos@MIT.EDU
Date: 1 Nov 1995 12:58:04 -0800
From: hyc@troy.la.locus.com (Howard Chu)
Could someone please explain to me why there is an application-specific version
string in the header used by sendauth & recvauth? In Kerberos 4 this string
existed but the recvauth function ignored it - just passed it on to the caller.
In Kerberos 5 the recvauth function compares it to a string specified by the
caller, and on a mismatch the recvauth transaction fails.
This seems like a misfeature to me. Why is it any business of the Kerberos
library to be concerned over an application-specific piece of information? The
information is clearly outside the realm of Kerberos; the Kerberos library
has no business aborting the transaction because the application versions
don't match.
Enforcing a match in the Kerberos library means either that when Kerberized
applications are upgraded, all clients and servers need to upgrade
simultaneously, or that the version string must be left unchanged, to allow
older clients to continue to work with new servers, and vice versa. The former
situation is impractical on any significant scale, and the latter renders the
application version string meaningless. If an application-specific tag belongs
here at all, it would be far better to go back to the K4 behavior - just pass
the string back to the caller, and let the server decide what it wants to
accept. Personally I believe the tag doesn't belong at all; any application
that depends on client and server versions either does or ought to already have
some other mechanism of negotiating compatible version info.
Even if the tag is left in the protocol, the current setup is inadequate; it
gives no provision for *negotiating* - the server just tells the client "bad
version" and the client has to *guess* what might be an acceptable version,
and try the whole thing all over again. A proper negotiation would be something
like what the telnet protocol uses for options, where both sides mutually agree
on supported sets of features. But of course, such a negotiation mechanism is
*clearly* beyond the scope of the Kerberos sendauth/recvauth transaction. Which
brings me back to the conclusion that the application-specific version tag
doesn't belong there at all.
--
Howard Chu Principal Member of Technical Staff
hyc@locus.com Locus Computing Corporation
