Porting Heimdal's libkafs to MIT Kerberos

[Douglas E. Engert]

Sam Hartman wrote:
> 
> >>>>> "Steven" == Steven Michaud <smichaud at pobox.com> writes:

> 
> Fundamentally we're in this mess because the OpenAFS project has
> resisted adding Kerberos dependencies to AFS.  IT's a hard problem and
> I respect that they don't have the resources to do it.  But putting
> the problem off on the Kerberos vendors is also not OK.

I totally agree.  But it is more then just Kerberos support, it is
goes to the question of what is the difference (if any) between an 
AFS cell and a realm?

I would argue that if the cell name = realm name and principal names match 
in both and then they are identical and no krb524d service is needed. 
AFS is just another service in the realm. 

If the names don't match or mappings between Kerberos principals to AFS 
username are needed, then you need a mapping service which is what krb524d
is doing among other things.  

What AFS really needs is a token issue service, which can accept 
K5 authentication and issue tickets, and do mappings if needed. 
 
And I know some of you may not want to hear this again, but that 
is exactly what the gssklog and gssklogd do!

Gssklog uses GSS to authenticate, and returns an AFS token protected by 
the GSS wrap. It does not even have to use the Kerberos gss, it can
use Globus GSI.  It can do any realm to cell name mapping, as needed. 

The current gssklog use TCP, and is linked with one implementation of 
gssapi. But its successor could use SASL and RX for example, and thus
totally be supplied by OpenAFS, and use whatever gssapi is available
on a platform. It could be MIT, Hiemdal, SEAM, or Microsoft SSPI.  

Thus on the client side at least, it could use any SASL, gssapi or Kerberos
and get OpenAFS out of the problem of whose Kerberos to ship with.  

Internal to AFS is the token, which does not have to be a Kerberos ticket,
but could be. The current client side hack using a K5 ticket as the token
really shows that the client does not need very much Kerberos code, and
if done carefully, would not need much more. (Newer encryption code
is the biggest problem for AFS.)

> 
> Kerberos has one fundamental interaction with AFS.  The krb524d
> supports a special protocol for AFS tickets because of the v4
> transited realm attack; this is a very big hack but besides this,
> there is no reason the MIT libraries or KDC needs to know about AFS.
> 

> MIt developers currently are AFS users and some of us are familiar
> with AFS issues.  There is no guarantee this will remain true.
> 
> Why is AFS special besides historical reasons?  Other than historical
> decisions, why should Kerberos implementations contain code to deal
> with AFS rather than AFS implementations contain code to deal with
> Kerberos?  If MIT chooses to integrate this code how will we avoid
> opening the floodgates to vaguely related technologies?
> 
> So, what would I like to see happen?  I'd like to see AFS
> implementations pick up libkafs or some similar functionality.  I'd
> like to see them provide a tool for finding afs libraries including
> libkafs.
> 

My argument is that libafs needs to be reviewed. Maybe it is totally
out of date and needs to be replaced by OpenAFS providing the interfaces
to use multiple underlying method, like gssapi.  

> I'm open to arguments about why the Heimdal design decision is
>  correct.  I have already considered the historical argument.
> 
> All the above not withstanding, MIT Kerberos is open source software.
>  You can take it and modify it as you see fit.  We don't have to take
>  your patches; you don't even have to offer them or allow us to take
>  your patches even if we want them.  We'll cooperate more with people
>  who are working in the same direction we are, but you can always go
>  take our code and do whatever you want with it.
> 
> --Sam
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

-- 

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