On Tue, 17 Feb 2004, Jan Harkes wrote:

> The problem is that kerberos might go off and do something like a
> blocking DNS lookup, or long computation without yielding control to
> other LWP threads. This isn't much of a problem in clog and auth2, but
> for Coda clients and server such a thing would be deadly as it leads to
> disconnections. And then we have to reestablish the RPC2 connections
> which requires authentication which might block in kerberos, which leads
> to disconnections...

It relates not only to Kerberos, but to gss-api as well.
Reading http://www.rfc-editor.org/rfc/rfc2078.txt :
--------------------------
For mech_types which require interactions with third-party servers in
order to establish a security context, GSS-API context establishment
calls may block pending completion of such third-party interactions.
--------------------------

Still, for token acquisition, gss-api can be a nice wrapper for several
authentication types, possibly including Kerberos (though incompatible
with the existing Kerberos support).

Given a modular clog, one source could be linked with different gss-api
libraries to produce several corresponding modules.

Mark Phalan wrote:

> I have been working on adding GSS-API authentication to auth2 and clog -
> it uses GSS-API to authenticate and then wrap the coda tokens for the
> client who can unwrap them and use them. I haven't looked at what venus
> does with those tokens (in fact I don't really have a clue) but at least
> the authentication part is basically there.

Mark, would you mind to share your code?

Jan, I would volunteer to add gss-api (krb5 and gsi) to the modular clog
suite... should be pretty much straightforward.
(I assume you did not touch that code and no coordination of changes is
necessary)

Regards,
--
Ivan