[OpenAFS] Some questions about the future of OpenAFS

[Douglas E. Engert]

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. 
But the krb524d is running on the K5 KDC machines, where as the gssklogd
runs on the AFS machines. The problem is the krb524d only speaks Kerberos.

> But
> then what you're saying is this service can be set up in 2
> wire-incompatible ways (GSI and krb5 GSS)?

Yes. Right now, you could run two seperate gssklogd's on seperate ports,
one for K5 and one for GSI. (Eventially I would like to use mech-glue so its
a single server.) They each accept an autheticaiton, then map the 
authenticatd user to an AFS user in the cell. They run independent of
each other, and any kasrver which may also be running. This works because
they all have access to the /usr/afs/etc/KeyFile so can create tokens
for the cell.
 
> 
> > 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.
 

> But given the cache manager
> portion of the work (which effectively is involved in "whatever a token
> becomes") is probably more difficult than the rest, and that progress is
> already being made on the rest, this still doesn't look like a big win in
> the future, especially if it means yet another external dependancy over
> what would already have been needed gets pulled in... and especially if
> that dependancy is OpenSSL.

The external dependence is not on OpenSSL or GSI, it is on a GSSAPI
implementation in a shared library or DLL, a plugin so to speak. If my site
wants to use Entrust's SPKM GSSAPI, or the Microsoft GSSAPI over SSPI so be it.
If there is a GSSAPI compliant shared lib, there should be no changes needed 
to AFS to support this.

I would like to work with you on this, so that the multiple authentication
methods could be included in a future release. 
 
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

-- 

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