* 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. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info