[6127] in Kerberos
Re: K5 recvauth
daemon@ATHENA.MIT.EDU (Howard Chu)
Sat Nov 4 19:13:53 1995
To: kerberos@MIT.EDU
Date: 4 Nov 1995 15:58:26 -0800
From: hyc@troy.la.locus.com (Howard Chu)
In article <479n6q$jn9@jik.datasrv.co.il>,
Jonathan Kamens <jik@jik.datasrv.co.il> wrote:
>The application version string supported by V5 sendauth/recvauth is just a
>convenience. If a particular application wants to allow negotiation as you
>describe, then all it has to do is define its protocol so that its clients and
>servers always specify a null string for the application version string to
>sendauth and recvauth, and then the client and server can do their own
>negotiation, using their own protocol, after the sendauth/recvauth is
>completed successfully.
>On the other hand, if the version-string checking functionality were removed
>from the V5 sendauth/recvauth as you propose, then every application that just
>wanted simple version-string checking, without confirmation, would have to
>implement essentially the same code (to transmit the version string and verify
>it in the server). Why should applications have to do that when it's just as
>easy to make the code globally available in V5 sendauth/recvauth?
>In summary, the existing code doesn't prevent any application that wants to do
>negotiation from doing so, and it assists applications that don't want to do
>negotiation. So I don't think there's any problem.
This is a nice, reasonable argument, but still it does nothing to address the
problem of version updates. Perhaps all I'm really struggling with here is the
terminology; if an application wants to use the string as a simple tag just
to distinguish itself from foreign applications, that's fine. Then it just
becomes an "application name" instead of an "application version" string. But
if you go about setting a "version number" on something, that pretty much
implies that you expect future versions to come about, which will have different
version numbers, and this mechanism is unsuitable for such situations.
As an example, the MIT-distributed popper source uses a string "KPOPV1.0". With
the current code, there can never be a "KPOPV1.1" or any other version, because
making such a change would break every existing Kerberized POP client. As such,
this string is really only useful as a name specifier, not a name&version
specifier. As a name specifier, it's redundant though - the AP_REQ message
already specifies the service that was requested. And the AP_REQ decoding also
comes for free, for the benefit of simple-minded apps.
I saw a comment about preserving backward-compatibility, but that seems a
little flawed to me as well, since the current behavior is not compatible with
the K4 behavior. I have a nicely integrated Windows library that does both
K4 and K5 in one package, and a Kclient wrapper library that will transparently
use either protocol. Apps like Eudora could use this library to talk to either
K4 or K5 pop servers, without rewriting a single line of application code, were
it not for this seemingly-insignificant change in recvauth. This is intensely
annoying.
Assuming application writers recognize the limitations of the current
implementation, and avoid using the app-string at all, there is no problem. But
a naive programmer who tries to put something meaningful into this string is
bound for frustration, the first time the app gets revised. And face it, any
significant piece of code is going to be revised a few times in its lifetime.
Providing this "simple version checking" for programmers is merely inviting
them to shoot themselves in the foot.
--
Howard Chu Principal Member of Technical Staff
hyc@locus.com Locus Computing Corporation
