[6159] in Kerberos
Re: K5 recvauth
daemon@ATHENA.MIT.EDU (Howard Chu)
Tue Nov 7 21:16:43 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 17:51:49 EST.)
<9511072251.AA08328@dcl.MIT.EDU>
Date: Tue, 07 Nov 95 18:06:01 -0800
From: hyc@locus.com (Howard Chu)
Cc: kerberos@MIT.EDU
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 recvaut
h
demands that my client send the correct application-version string, or els
e
it disallows my authentication attempt.
Why do you need application version compatibility with KPOP? Why do you
want to change the application version number at all?
I don't want to change the version number. I don't want to have to know
anything about the version number at all. In K4, the application version
number could simply be ignored, with no ill effects. In K5 the client has
to get it right, or else.
You keep talking about aggravatingly high levels of frustration, but
you're not telling us what you really want to do. This makes it much
harder for us to help you, and thus increases the likelihood that you
will be frustrated. I'm sorry, but there's not much I can do about that
unless you're willing to tell us a bit more about what your real agenda
is. This is the first time that you've even mentioned KPOP and even now
I don't know why you want to mess with the application version.
I'm sorry, I thought I had mentioned KPOP prior to this. That must've only
been in the newsgroup. And again - I don't want to have anything to do with
the version string.
Here's the complete situation - I have an integrated K4 and K5 library for
Windows. I want to enable naive callers to authenticate to K4 or K5 services
without them having to know anything about the underlying Kerberos protocol.
Part of this is accomplished by plugging in a front-end using Cornell's
Kclient API. In particular, I want to have Kerberos authenticated POP sessions
using either K4 or K5. The Eudora client from Qualcomm already uses Kclient
for K4 authentication to K4 POP servers. All it does is call a
GetTicketForService function, and sends the resulting data uninterpreted to
the POP server. My Kclient front end can return a K5 ticket for Eudora to
use, but in order for the POP server to accept it, it has to have the correct
application version string attached. This is an unreasonable requirement.
For POP and K5, the long range solution is not sendauth/recvauth, at
least not in my mind. No vendor is currently supporting K5 KPOP, and
quite frankly, I hope no vendor does. KPOP is non-standard; it's not
Whether or not any commercial vendors have supported it so far seems a
non-issue here; the Kerberos source has been available for a long time
and people are using it, independent of what any vendor decides.
defined by any RFC, and it needs a non-standard port. I probably
shouldn't have continued distributing the version of POP in the K5
distribution; that was a mistake on my part, and I apologize.
The long-term solution with POP is to use the POP3 AUTHentication
command. This is described in RFC-1734, and it allows you to add GSSAPI
authentication to POP using the standard POP protocol. The protocol
definitions are all documented in RFC standards documents, and thus
significantly increase the chance of interoperability.
That sounds very nice, but for sure no one is doing anything like this yet.
My goal was to produce something that would just plug in to existing
apps, requiring no modification in the client itself. This seemed a worthwhile
goal since there are a number of apps out there that use these existing
interfaces, however unofficial they may be.
The only applications which are using sendauth/recvauth are the Berkeley
login suite, and the POP applications. I consider rlogin/rsh/rcp to be
a hopeless mess as far as their protocol and implementations are
concerned, and I'm hoping that once kerberized telnet and ftp are
available and widely used, that we can drop support for rlogin
altogether.
That would be nice.
As far as POP is concerned; you're right, we shouldn't have included
them in the distribution. (Is anyone actually using them? If not, I
may just drop them altogether.) The problem is that I haven't had the
time to write a GSSAPI version of the POP clients yet; if you or someone
else would be willing to sit down with RFC-1734 and a recent version of
Berkeley popper, and integrate the POP3 AUTH command using the GSSAPI
calls, that would be doing the community a real service.
I would try to do this, but my own development deadlines have slipped a lot
recently, thus adding to my personal tension in this matter. It looked like
we could take what currently existed and modify it simply, with a minimum of
time and fuss. Now it's coming down to the difference between releasing a
suite of Kerberized apps on time or not at all. Clearly that's no one's problem
but my own.
This is clearly going to take some time to get it done right. I'm not sure
I can take that time. Whatever solution has to also support K4 mechanisms,
because we also need to deploy in AFS environments. GSS won't help us there.
Ok. That's more than enough to think about for now, I'll quit bugging you
until I figure out where I want to go next.
-- Howard
