I have just successfully gotten Coda 5.0.1 to work with MIT Kerberos5
1.0.5 (after figureing out the coda server needs a Krb5 host
key/principal)

I built RPMS of coda and kerberos, and included the Krb5 PAM module to
allow logins, etc. If anyone wants these, let me know. Q: Can I send an
rpm spec file outside of the US and not violate export regs?. (If not, I
could snail-mail a diff or the spec to someone)

I'd like to offer to help with the KrbV and PAM modules, since I would
find them very usefull. ;)

I also have a couple of feasability questions, now that I have a better
idea what's going on. How hard would it be to:

1) use Kerberos as the authentication/encryption mechanism all the way
though Coda? (This might be a way to get around encryption export stuff,
since krb5 can be gotten from replay.com and there is a free krb4 clone in
Europe somewhere)

2) make direct use of kerberos principals so that say, anyone with a
joeuser/admin principal can be a member of the System:Adminstrators group
while the regular joeuser principal is not. (along these lines, this would
allow a joeuser/cron or joeuser/daemon principal to get coda tokens for
cron jobs or such from a kerberos ticket the user has left for that
purpose, via a ticket with an extremely long lifetime)
This might also solve the "how do I authenticate the web server" type
problems. (Correct me if I'm wrong, but could having a host key/principal 
for the webserver machine allow this?)

3)
   a) automatically get coda tokens from kerberos tickets if they exist
	or
   b) use kerberos facilities to replace coda tokens (this sorta goes with
      (1) above)

4) This is more of a kerberos thing, but krb5 has the DES3 code
   modularized, so what would it take to update the krb5 encryption code
   to use something like blowfish and friends?
 

On Sun, 7 Feb 1999, Robert Watson wrote:

[snip] 
> However, I am in the process of finishing up a set of patches and
> additional source files that add:
> 
> a) HMAC-MD5-based integrity checking in all verisions of Coda (hash is
> configurable, and pluggable)
> 
> b) Support for strong encryption (HMAC,3DES) (US-only) as well as weak but
> exportable (XOR) and none (none) (exportable).  The default state for
> connections is set as a global policy for the client. New algorithms may
> easily be added.
> 
> c) Improved support for KrbIV and KrbV in the environment.
> 
> I'm also looking at writing PAM modules to support Coda + Kerberos, but
> because of the heavy-weight nature of the threading/rpc system, my
> tendency is to move the token-acquisition into a seperate authentication
> daemon on the client.  This would also allow for less-coda-like
> authentication that some have been looking for during transitions to
> distributed authentication.
> 
> So far most of this work is done--encryption/authentication all appear to
> work quite nicely; I'm working on a new binding currently to replace the
> requirement for encryption during the binding, as it is used for a key
> exchange and is as weak as the encryption (and hence the exportable
> version would suck).
> 
> I hope to have the new binding ready for testing sometime in the next day
> or two.
> 
>   Robert N Watson 
> 
> [email protected]              http://www.watson.org/~robert/
> PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C
> 
> Carnegie Mellon University            http://www.cmu.edu/
> TIS Labs at Network Associates, Inc.  http://www.tis.com/
> SafePort Network Services             http://www.safeport.com/
> 
> 

--------------------------------------------------------------------------
| Troy Benjegerdes    |       troy_at_microux.com     |    hozer_at_drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------