[OpenAFS] non-kerberos authentication mechanisms for afs?

[Sergio Gelato]

* Adam Megacz [2005-03-19 00:42:44 -0800]:
> My only gripe with Kerberos is that two non-admin users can't set up a
> trust/permissions relationship without involving their kerberos admins
> (ie adding principals), or having a kerberos server in the first
> place.  Sometimes the former just isn't possible (paranoid sysadmins
> won't create principals because they think it's a "security risk").

I'd call it an "administrative burden" rather than a "security risk".

> What I'd like to do is create some ugly hack that allows you to use an
> OpenPGP key fingerprint in an ACL.

Let's generalise a little bit and talk about PKI-based authentication
(not necessarily PGP; other kinds of public keys will do just as well).
I'd want to use the full public key rather than the fingerprint.

> The goal here is to have a single, worldwide namespace (openpgp
> fingerprints) for authentication the same way we have a single,
> worldwide namespace for file paths (/afs).

Kerberos 5 already provides a single namespace for principals. The trouble
(from your point of view) is that trust is a matter of realm policy, with
the end user being constrained by administrative fiat. So you're proposing
a mechanism for users to (effectively) register their own principals. One
way to do it within a Kerberos framework would be to give each user his/her
own realm to administer and establish a trust relationship with it. (No, 
I don't advocate actually doing this, at least not on a large scale; 
I only mention it as a possibility.)

> Clearly this would require a lot of changes on both the client and
> server side.

Maybe not much more than what is already needed to support GSSAPI in
OpenAFS 2.0.

>              I'm wondering if it's easier to set up a "kerberos to
> pgp proxy" that will pretend to have an instance for any keyprint you
> choose, and will issue you a tgt if you can prove that you hold the
> private key.  Then it would just be a matter of writing this "fake
> kerberos server".

Hasn't Microsoft been working on something like this? (Not to forget the
proponents of tools like gssklog...) Anyway, I think it's clear that the
exact same problem would need to be addressed for, say, NFSv4, so it 
deserves to be solved at the Kerberos/GSSAPI level rather than within 
AFS itself.