[6153] in Kerberos
Re: K5 recvauth
daemon@ATHENA.MIT.EDU (Howard Chu)
Tue Nov 7 17:37:18 1995
From: hyc@locus.com (Howard Chu)
To: Theodore Ts'o <tytso@MIT.EDU>
Cc: kerberos@MIT.EDU
In-Reply-To: (Your message of Tue, 07 Nov 95 14:58:21 EST.)
<9511071958.AA08128@dcl.MIT.EDU>
Date: Tue, 07 Nov 95 14:18:41 -0800
First of all, the use of sendauth/recvauth is something which I would in
generally recommend against using. It's provided as a convenience
function for someone who wants to hack a quick kerberized client/server
application together. However, for anything that's going to be more
enduring --- and the way you talk about version numbers and backwards
compatibility, it sounds like it is, I would recommend either using the
GSSAPI, or if you need specialized features of the Kerberos protocol
like user-to-user authentication, which aren't supported by the GSSAPI
(or by sendauth/recvauth I might add), then you should use the native
Kerberos API directly.
I understand that use of sendauth/recvauth is not encouraged, but in this
case I have no choice - the Kerberized POP servers of the world already
use recvauth. Whether or not I use sendauth is irrelevant - the K5 recvauth
demands that my client send the correct application-version string, or else
it disallows my authentication attempt.
I'm not trying to create a new application protocol here. I'm trying to
deal with a protocol that you guys created in (K4) and you guys used in
a number of applications that you ship in your publically distributed code.
I'm trying to deal with what I consider an obvious flaw, but the only real
solution for this flaw is for you to *change* the K5 recvauth, and make it
behave like the K4 recvauth did. Either that or make sure that general-use
servers that are included in the MIT Kerberos distributions stop using this
ill-conceived function.
It's certainly fine for rlogind, since the only thing that can legitimately
talk to it is a kerberized rlogin client, and everyone uses the BSD-derived
client code. But a POP server, or an HTTP server, or any other general
information-distribution service is very likely going to be used by dozens
or even hundreds of different clients all of unrelated origin. Requiring each
of these client developers to maintain such a trivial piece of information
in their clients just to talk to a braindamaged authentication function is
ludicrous.
Yes, I've lost my temper here. This is an aggravatingly insignificant
implementation issue but it's causing an aggravatingly high level of
frustration. You folks have created a situation that just isn't right. All
I'm asking for is a simple solution. If you want to back away from recvauth
and say its usage is not recommended, fine. But what the hell are we supposed
to do about the services that are already in use, using this stupid thing??
-- Howard
