[OpenAFS] Some questions about the future of OpenAFS

[Douglas E. Engert]

Jeffrey Hutzelman wrote:
> 
> On Tue, 30 Apr 2002, Douglas E. Engert wrote:
> 

> 
> Actually, you have it backwards.  gssklogd is acting much like a krb524d
> with a single service key. OK, it depens on your view. But the gssklogd
is not tied to K5. 

> 
> > But the krb524d is running on the K5 KDC machines
> 
> Actually, that's never been a requirement of krb524d.  It's always been
> possible to run krb524d in a single-service mode running on the same
> machine as the application server, or wherever else you want to put it. I
> believe there are people using this configuration today to authenticate
> AFS clients against a Win2k KDC.

And we are doing this today too. The krb524d run on Solaris.

> >
> > Yes, that's the idea. The authentication is done via GSSAPI. A token
> > is then created. The gssklogd today, is creating the K4 token, and uses
> > code form OpenAFS. In the future, I would expect it could create whatever
> > type token you decide upon. One problem today is that the creation of the
> > AFS token is so embedded in the old AFS code, that I had to copy and hack
> > at it to get it into the gssklogd. I am hopping in the future, that
> > you make the creation of the token separate from the transport and
> > authentication code, thus making the gssklog a much simpler program,
> > and that you would include it or something similar in the distribution.
> 
> You're making a big assumption here.  You're assuming that we will always
> have this concept of an "AFS token" that is a chunk of data containing an
> encryption key and some authenticated representation of a user's identity.
> In short, you're assuming we'll always have something that is functionally
> the same as a Kerberos ticket, and then asserting that your tool will be
> able to kludge the Kerberos-ticket-like-thing into any auth protocol.

Well, that is what you have today. In the future, if you provide alternate
means of authentication we will use that. Any time frame for these changes?

The gssklog works today with the Transarc AFS and the OpenAFS. I almost have 
it working in WIN32 too.  

> 
> While that's fine as far as it goes, it turns out that the assumption is
> not only problematic, but provably false (more on that in a moment).
> 
> 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.

I know. So it is starting to sound like AFS will turn into DFS, at least
for the authentiction. Keep in mind foreign users, and cross cell/realm support. 

> 
> 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.

Well good, when its available, I will give it a try.  But keep in mind 
that AFS has succedded partly because of its simplicity, and easy 
instalation.  

We still need a way to use GSS with GSI to access AFS as an alternative
to any other GSS which you may want to use internally. So I will continue
to work on the GSSKLOG, and adapt it as needed. 

> 
> > I would like to work with you on this, so that the multiple
> > authentication methods could be included in a future release.
> 
> I'll be happy to talk to you offline about the state of ongoing work to
> integrate GSSAPI support into Rx and AFS.
> 
> -- Jeff

-- 

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