[OpenAFS] Kerberos 5, AFS, and no krb524d

[Douglas E. Engert]

Rodney Dyer wrote:
> 
> At 03:09 PM 6/6/03 -0500, Neulinger, Nathan wrote:
> >Then you have a "big project" maintaining compatability with lots of
> >kerb distributions, instead of a small project doing so.... Latter is
> >much easier to maintain I believe.
> 
> Why?  Far be it from me to make this supposition but I'm going to.  There
> exists one open source project for AFS and as far as I'm concerned one open
> source project for Kerberos.  If AFS is going to transition to Kerb 5, then
> it should use a Kerberos open source project to "meld" with.  If I'm not
> mistaken that's the MIT Kerberos distribution.  Are there others of any
> significance?  Please tell me if there are because I haven't heard of any.
>

See previous responders. 
 
> Let's see a show of hands of AFS user's who want to transition to Kerb
> 5?  Let's see a show of hands of user's who wouldn't mind the "klog -mitv5"
> command calling the MIT distribution's Kerberos library interfaces?
> 
> >I think that's the end goal, but getting there will be a while. We
> >currently don't have any dependency or integration of krb5 at compile
> >time into the openafs build. Maybe we should, not clear.
>

The end goal should be to keep AFS flexibly enough to work with any 
authentication system in a secure manor, and to not get it tied to closely
to any one.  This may be some version of Kerberos or some other authentication
system. AFS is a file system where the client and file server need to communicate
on behalf of some user who has rights to access files. 

Internally AFS has used K4, and provided its own KDC and other Kerberos services
to support itself. We are now talking about converting this to K5, and using 
external KDCs and additional services.  

But what AFS really needs to operate as a File Service, is a token. The token
has the authentication information, session keys and is encrypted in one of 
the AFS service keys (The ones in the /usr/afs/etc/KeyFile.) It can get this 
in a number of ways. It depends on who holds the AFS service keys. The AFS 
servers have a copy, and some external service, like a KDC could hold a copy. 

This is the way we run today. The k4 kaserver still works 
and it produces tokens encrypted in one of the keys. Other people use
the aklog (we call it ak5log), to krb524d. In our case the krb524d
has a copy of the AFS service keys, and it translates K5 tickets 
from two separate realms (One a W2k AD and the other an MIT based realm)
to the K4 ticket for the AFS cell, and encrypts
the ticket in one of the AFS keys. (The standard aklog, has the KDC
hold a copy of the key, and both the K5 ticket used for the krb524d and the
k4 ticket returned use the same encryption key.)    

We also have two versions of the gssklog. The gssklogd holds a copy of the 
AFS service keys, and produces a K4 ticket. One version uses the Kerberos 
GSSAPI, the other the Globus GSI  which uses X509 certificates.

In all of these cases the AFS client cache manager ends up with an AFS
token that the client can use with the server, on behalf of a principal
which can be looked up in the PTS. 
 
> Yes, you should.  Otherwise AFS is going to languish in the back waters
> from a LOTR Gollum type schizophrenia of indecision...should we, or
> shouldn't we, should we, or shouldn't we.
> 
> The only real standard on Windows machines for Kerberos authentication is
> through the SSPI.  And I'm pretty sure you don't want to go that
> route...right? 

NO, I would like to see this as one of the choices! I would like to see
AFS be able to run on a Windows machine with out any addition Kerberos
software packages, other then what AFS provides internally. 
 
I am not saying that the AFS client to the AFS file server needs to use SSPI,
but the initial token could be obtained using SSPI to the gssklogd. (SSPI
use the K5 gsspai protocal.)  

> So, it's either MIT's distribution or nothing else.  You
> might argue that there are lots of Kerberos distributions, but are they
> open in any sense of the word?  Why tie the OpenAFS project to close source
> distributions?

No, its the AFS token is is using some format, K5 is a good choice, Internally
AFS can then use any package it wants to process this, and can even ship with
a subset of the Kerberos, as it does today. 

It comes down to how is the token obtained, and does there need to be
any intermediate sevice to rewrite the token, such as krb524d, or gsklogd.  

> 
> Hmm...just thinking...for the Windows users...so would it be possible to
> create an AFS K5 service principle on Microsoft's AD server, then request
> that service principle, strip it clean, then stuff it into the AFS token
> cache? 

Yes, that is very possible.

 I suppose the salts would be a problem here.  But, if you could do
> this, you wouldn't need the krb524 code right?

No, the salt has to do the authentication of the user. It has nothing
to do with the actual AFS token. You are thinking it is a one setp process, 
but it is a two sete process, authentication to a third party, then obtaining 
the token. 

> 
> Anybody got any ideas in this direction?  Am I talking out of my Uranus?
> 
> Rodney
> 
> _______________________________________________
> 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