(Illustration by Gaich Muramatsu)
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 > > robert@fledge.watson.org 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 | --------------------------------------------------------------------------Received on 1999-02-07 20:37:48