[OpenAFS-devel] File copying

[Jeffrey Hutzelman]

On 6 Jan 2001, Sam Hartman wrote:

> >>>>> "Chaskiel" == Chaskiel M Grundman <cg2v+@andrew.cmu.edu> writes:
> 
>     Chaskiel> Excerpts from internet.computing.openafs.devel:
>     Chaskiel> 5-Jan-101 Re: [OpenAFS-devel] File co.. by Sam
>     Chaskiel> Hartman@mit.edu
>     >> If you do this, consider the implications for RXKAD3, where
>     >> servers will have individual keys.  Be prepared to address how
>     >> servers determine the copy is authorized.
>     Chaskiel> Since when will rxkadv3 require individual server keys?
>     Chaskiel> The problem of the "are we using krb4 and fcrypt or krb5
> 
> If you are using GSS (which is distinct from krb5 and GSS; there are
> good techntical reasons not to assert krb5 specific gss support), then
> you want to minimize manual handling of the gss names as you can't
> really portably do much with them.  This mostly forces eachs server
> into its own security domain.

I don't see rxkad v3 as providing any more application-specific or
mechanism-specific knowledge than GSSAPI itself does.  Just like any other
GSSAPI-using application, an application that uses rxkad v3 will have to
specify what service name(s) it uses, possibly on a per-mechanism basis. I
wish we could do better than this, but the problem is in the GSSAPI and I
see no clean way to fix it at a higher level.

I would certainly like to see openafs support per-server keys, but the
issue is in my mind completely orthogonal to the transition away from krb4
and fcrypt to more useful authentication mechanisms and cryptosystems.

It seems to me that the OpenAFS implementation will need to provide some
mechanism for mapping a cell name and fileserver identity (hostname? UUID?
IP address?) into an appropriate GSSAPI service name.  For many cells,
that may simply be 'afs@cell.name'; for others, it might be
'afs-server@file.server.fqdn'.  In either case, this is nontrivial, since
an AFS cell name is not necessarily a hostname, and the hostnames of
fileservers are not contained in the VLDB -- it only has IP addresses and
UUID's, neither of which can be securely mapped to a hostname by the
client.


-- Jeff