[6156] in Kerberos
Re: K5 recvauth
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Nov 7 18:08:10 1995
Date: Tue, 7 Nov 1995 17:51:49 -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 14:18:41 -0800,
<9511072218.AA25344@troy.la.locus.com>
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 recvauth
demands that my client send the correct application-version string, or else
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?
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.
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
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.
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.
Why is it a real flaw in practice? Why do you want to change the
application version number? And why can't you solve the problem by
doing the version negotiation somewhere else? For example, you can add
a command to the POP protocol which indicates to the server that the
client wants some new functionality. If the change you want to make in
the POP protocol is mail releated, arguably that's the better way to do
it anyway.
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.
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.
- Ted
