[OpenAFS] final prerequesite for world domination [was: what is aklog's algorithm...]

[Douglas E. Engert]

Adam Megacz wrote:
> Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:
> 
>>--Ken (who wrote the initial support for RFC 2052 for MIT Kerberos).
> 
> 
> Thank you, Ken.  You, the person who came up with AFSDB, and the
> person who implemented dynroot are my heroes.  You've made a lot of
> things possible for a lot of people.
> 
> Now all we need is a widely-accepted, widely-adopted way to
> authenticate users who are not in the kerberos database of the local
> cell, and do so without administrator intervention (ie without adding
> a ridiculous N^2 cross-realm entries).  Ideally this would also include
> users who do not have a kerberos identity in *any* cell/kdc, anywhere.
> 
> There are a lot of competing solutions and partial-solutions out there
> (gssklogd, kx509, pkinit), but I think widespread agreement will
> matter most in the end.  Whatever solution manages to prove itself
> worthy enough to the gatekeepers to get included in the "stock"
> OpenAFS will end up becoming the de-facto standard that everyone uses.

Well, I can speak for gssklog, It does not do identity management.
It uses some gssapi mech to authenticate and then issue an AFS token.
The gssapi could be Kerberos. The gssklog was original developed to work
with the Globus GSI at sites that had AFS and Globus but no Kerberos v5.
Globus uses x509 certificates and so the identity management is done by
the PKI infrastructure. The gssklogd does do some simple mappings of
identities from the gss_name to the AFS username. But this still relies
on outside identity management.

> 
> There's no reason why AFS can't offer/support a PKI mechanism that is
> as easy to use as the SSH keying mechanism.  When I can do "fs sa file
> joe.key write" [*] and joe doesn't have to put much effort into
> configuring his client to use his key, then I think the stage will
> finally be set for a single world filesystem.
> 
> Bring it on.
> 
>   - a
> 
> [*] Where "joe.key" is a *file* containing some cryptographic public
>     key for some person joe who is not [yet] in the pts database.
>     The mechanics of how this actually would work is a good topic for
>     discussion.
> 

-- 

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