[OpenAFS] Some questions about the future of OpenAFS

[Matthew N. Andrews]

Jeffrey Hutzelman wrote:

>
>The problem is that in order to invent a "new token" that fits your
>assumptions, we essentially have to reinvent large parts of Kerberos. We
>have to reinvent something like a ticket, and something like an AP_REQ
>exchange, and maybe something like a TGS_REQ exchange (if you want
>different servers to have different keys).  We have to reinvent the
>concept of multiple enctypes, and define semantics for how you can know
>which ones to use for a given client, auth server, and fileserver.  I know
>you _know_ these are hard problems.
>
>Work is ongoing _today_ to add real GSSAPI support to Rx.  Once this work
>is done, and appropriate integration work complete, there really won't be
>a concept of a "token" as a data object you pass around.  What you'll have
>is a process or library that knows how to establish GSS contexts on the
>user's behalf.
>
So, is the intent here to use something like mech-glue to allow you the 
client, and server to negotiate a particular type of gssapi 
authentication, or will users simply not be able to authenticate to both 
cell a, and b from the same machine if the two cells use different 
gssapi libraries? one of the things that makes afs an attractive 
solution to my users is that they can access calls a, b and c all from 
the same machine just by running klog for each of them.

I like the idea of being able to replace my underlying auth mechanism if 
something better comes along, but there is definately a lot of value to 
maintaining compatibility between afs cells.

just my 2 cents.

-Matthew Andrews