[OpenAFS] Some questions about the future of OpenAFS

[Jeffrey Hutzelman]

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

>
>
> Derrick J Brashear wrote:
> >
> > If I'm wrong on any of this, speak up. I certainly wouldn't mind at all
> > being wrong.
> >
> > On Tue, 30 Apr 2002, Douglas E. Engert wrote:
> >
> > > I like Kerberos, V5 not V4. We have used DCE security servers as KDCs in the
> > > past as well as W2K domain controllers. Both of which supported only V5. We
> > > are running the krb524 just for AFS. We would like to get rid of it. The
> > > gssklog with a Kerberos V5 GSSAPI can do that too.
> >
> > If you set up krb524d with just the service key (for AFS, which is what
> > you'd want anyhow) then you buy the ability to use non-DES keytypes for
> > things that authenticate to your service as compared to krb524d. Ok.
>
> With the krb524d mods we have today, the key used for the K5 ticket is
> seperate from the key used for the token. (The krb524d has a keytab file
> and access to a copy of the /usr/afs/etc/KeyFile.) This means I could have a 3des
> key for the K5 ticket. But due to AFS cachmanager and file server limitations
> the AFS key, and the session key in the token are still single des.
> So in effect the krb524d is acting much like a gssklogd with K5.

Actually, you have it backwards.  gssklogd is acting much like a krb524d
with a single service key.

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

> > > 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.
> >
> > Sort of. You're offering this as a way to take "any piece of
> > authentication data" and translate it now to "a DES key", and I assume in
> > the future "whatever a token becomes".
>
> 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.

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.

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.

> 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