I must warn that I'm not speaking from direct experience.

OK - here's my take on the situation from fairly long (1997 or so, I
think) experience with coda.


Coda security can be divided into three areas:

authorization model: Here coda has a well-thought-out scheme and a
reasonable implementation, with user and group permissions implemented
by acls on directories.  This model is based on authentication of
requests.

authentication and confidentiality of data traffic: Coda uses a scheme
that is much like Kerberos (a variant of Needham-Schroder, I believe)
to obtain tokens and use them to authenticate/encrypt messages.
This is tricky business, and I don't know if the coda scheme is sound;
perhaps Satya can comment, especially in light of:
http://citeseer.nj.nec.com/context/348225/0
which I think postdates the auth2 code.

However, the coda implementation uses XOR instead of a cipher because
of past export control rules.  Thus, no authentication and
confidentiality is actually provided.  An eavesdropper can easily
recover token keys from listening and then masquerade as the user.
Until this problem is fixed it is simply incorrect to call coda - the
implementation - secure.

code quality: To be secure, the clients and servers must be free of
exploitable defects.  I think the code is getting better over time,
but I don't have a warm fuzzy that it is all ok.

As a result, my practice is to require IPsec ESP for all coda traffic,
and to limit the set of hosts to which my server is willing to set up
IPsec SAs to ones that are more or less under my control.

There are at least two paths forward to solve the "XOR problem".  One
is to use AES instead.  This leaves us with a N-S protocol variant
(and, I think homegrown by people who are not cryptographers).

Another alternative is to replace the RPC2 N-S scheme with the use of
GSS-API wrapping, and then to use Kerberos.  This would rely on
well-reviewed security protocols that are believed to be sound.  While
Kerberos is non-trivial to set up, it isn't that much harder than
auth2.  One would replace getting tokens with establishing a binding
at the server from a kerberos principal to a coda uid (by consulting
the equivalent of .klogin, probably in some authentication database,
or by the obvious 'gdt._at_IR.BBN.COM can be coda user gdt in the
ir.bbn.com coda realm' mapping.  This binding setup would also
exchange the intiial GSS-API state, so that datagram wrapping could be
done on the rpc2 data.  Unfortunately, the code has not been written
yet.