[6162] in Kerberos
Re: K5 recvauth
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Nov 7 22:17:42 1995
Date: Tue, 7 Nov 1995 22:00:44 -0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: hyc@locus.com
Cc: Theodore Ts'o <tytso@MIT.EDU>, kerberos@MIT.EDU
In-Reply-To: Howard Chu's message of Tue, 07 Nov 95 18:06:01 -0800,
<9511080206.AA31586@troy.la.locus.com>
From: hyc@locus.com (Howard Chu)
Cc: kerberos@MIT.EDU
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.
If you're talking to the K5 POP server, the application version string
*WILL* be the hard coded string "KPOPV1.0". Nothing else will work, and
that string won't change, because of the interoperability issues. Aside
from your being aesthetically offended about this, I'm not sure why it's
unreasonable.
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.
Note that although a K5 POP server can listen on a port and support both
K4 and K5 POP service, the reverse is not true. If a V5 client tries to
initiate a KPOP transactoin to a V4 only service, it will get an error
and its only option will be to shutdown the TCP/IP connection. No
negotiation is possible, due to the nature of the V4 sendauth/recvauth
protocol. (Sorry, but sendauth/recvauth has always been a hack.)
For client side application, you're best off thinking about K4 and K5
KPOP (or POP with RFC 1734 authentication) as being different POP
protocols, at least as far as the initial protocol initiation is
concerned. The client will connect and do the V4 sendauth thing, or it
can connect and do the V5 sendauth thing, or it can connect and do the
official AUTH command as defined in the POP protocol. These should be
completely different code paths; after the initial authentication, you
can then use a common code base for doing the POP commands.
In the V5 sendauth case for KPOP, however, I am still completely
mystified why you are so bent out of shape over the need to hardcode the
string "KPOPV1.0" in your code. This is not a disaster, and this is not
hard to do. Why is this such a big deal?
- Ted
