[6149] in Kerberos
Re: K5 recvauth
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Nov 7 15:29:34 1995
Date: Tue, 7 Nov 1995 14:58:21 -0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: hyc@troy.la.locus.com
Cc: kerberos@MIT.EDU
In-Reply-To: Howard Chu's message of 4 Nov 1995 15:58:26 -0800,
<47gun2$221t@troy.la.locus.com>
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.
The sendauth/recvauth protocol is not documented anywhere, and it relies
on being able to "take over" a TCP/IP connection. This has benefits and
drawbacks. The benefits is that it makes the Unix program very easy to
use; it just calls krb5_sendauth(), and everything else is taken care of
by the utility.
However, the drawback is that krb5_sendauth() is syncronous, which is to
say it doesn't return until the authentication sequence is finished, and
that's death to Macintosh and Windows applications, since the event loop
doesn't get serviced while you're in krb5_sendauth(). What you really
need is an asyncronous version of krb5_sendauth(), with some kind of
callback or continuation function --- but how you write asyncronous
programs is extremely OS specific. Macintoshes do it one way, Windows
another, and X toolkit event loops use a still different way of doing
things.
Hence, the GSSAPI method of leaving the transport responsibility to the
application is a much more general and better way of doing things. The
disadvantage is that the application program has to do more work.
If an application protocol wants to do something fancy, and it really
wants to use krb5_sendauth/krb5_recvauth (which I wouldn't recommend for
a complex application) it can just put a fixed string for the
application version string, and do its own protocol version negotiating
after the sendauth/recvauth sequence is completed, outside of
sendauth/recvauth.
- Ted
