[OpenAFS] Some questions about the future of OpenAFS

[Derek Atkins]

Doug,

"Douglas E. Engert" <deengert@anl.gov> writes:

> So look at the separation of the authentication from the token
> generation as a way to give you, the OpenAFS developer, more
> flexibility in designing the next generation of the AFS
> token. Tokens don't have to continue to be Kerberos tickets, as they
> are used internally only by AFS.
> 
> This also allows the AFS cell to accept authentication by multiple
> means. The current klog and kaserver, the krb524d route, the K5
> GSSAPI and the GSI. Other could also be added too. Thus the AFS cell
> can be thought of separately from a Kerberos realm. The cell then
> represents the common set of servers which use the same
> authorization data base.

I don't particularly like this view.  The reason I don't like it is
that it views an AFS Cell as a coherent unit. I don't agree with that
view -- I see an AFS Cell as a collection of different servers that
collaborate to provide a file system.  What I'd like to see is the
client authenticate to _each server_ independently.

The problem with this view is that it makes an assumption about the
AFS token -- in particular, it assumes that the AFS client token can
be used to obtain individual tokens for each AFS server.  In other
words, your client token is effectively a TGT that is used to obtain
service tickets for each AFS server you contact.

Unfortunately this means that the AFS Token is even _more_ tightly
bound into Kerberos, as opposed to less-tightly bound as you are
proposing.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available