On Sun, 7 Feb 1999, sean dreilinger wrote:

> i set up a coda client this weekend, accessed the testserver at cmu, and
> am very impressed. 
> 
> after going through the setup docs and security paper on the coda web
> site, i still do not understand if communications beyond the initial
> authentication is encrypted.
> 
> the security writeup ``Coda Authentication and Protection'', linked as
> ``Notes and explanations about Coda securtiy.'' was interesting but
> still didn't make it clear whether coda is encrypting all communications
> or if the references to encryption in coda apply to the authentication
> process only.
> 
> if anyone on the list has a better clue than me, please share!

Sean,

Unfortunately, the sad state of the matter is that nothing in Coda is
encrypted except for that token exchange, and even that is only encrypted
using a trivial XOR-based encryption mechanism.  Integrity checking is not
provided for at all by the existing RPC2 code.

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/