[OpenAFS] non-kerberos authentication mechanisms for afs?

[Douglas E. Engert]

gssklog would only solve part of the problem. The AFS admins still get
involved, deciding what GSS to use, and with a X509, what certificates
what CAs are trusted.  In any case the AFS admins need to define the
mapping from the PKI to the AFS usernames.

How paranoid are your AFS admins?

Derek Atkins wrote:

> Sounds like you want gssklog, where you can convert any GSS credential
> (i.e., X.509 and/or some new PGP-based GSS mech) to obtain AFS tokens.
> 
> -derek
> 
> Sergio Gelato <Sergio.Gelato@astro.su.se> writes:
> 
> 
>>* 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
>>
>>
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444