There have recently been a number of messages pertaining to security
in Coda.  This level of interest in security is most encouraging, and
we should certainly continue the dialog.  At the same time, please
keep in mind where Coda is implementation-wise, and don't prematurely
rely on it for security.  To help the Coda community better understand
where things stand in this area, and where they are headed, we have
put together the following observations.

"Secure" vs. "Securable"
========================
It is useful to distinguish between Coda as a "securable" system
(which it is already), and Coda as a "secure" system (which it is not
at present).  In the high-level design of Coda and in its overall
architecture, careful thought has been given to security.  The
relevant system interfaces (RPC, Venus-kernel, client-server, etc.)
are structured to support crypto, strong authentication, etc.  To
ensure that these code paths are working correctly and don't atrophy
with new releases, the system today does support authentication,
acquisition of tokens or Kerberos tickets, encrypted transfers, etc.

In this sense, Coda offers the potential for better security than NFS
or other alternatives.  At the same time, the translation of Coda's
high-level security model into a genuinely secure system is still a
work in progress.  For example, there is support for multiple
encryption types but the only one currently supported is XOR.  This
ensures that the code paths work correctly when encryption is used,
but the actual level of privacy/integrity provided by its use is low.

In the past, progress in this area has been slow for two reasons.
First, the crypto export limitations dampened enthusiasm for working
in this area (this seems to be easing lately).  Second, we viewed
robustness of the basic Coda mechanisms more critical than ramping
up security.  Now that Coda is substantially more robust than
it was, say a year ago, we are moving forward to make it a really
"secure" system, not just a "securable" one.

We see a number of areas that need to be fixed in the coming months
for Coda to become truly secure:

 (a) support for one or more serious encryption methods, as well as
      cryptographic strength hashes for integrity protection

 (b) changes to the RPC packet formats, internal interfaces and protocols.
     These changes are needed to fix shortcomings that have come
     to light as we've thought through security support in more detail.

 (c) support for multiple "cells" or authentication "realms"; this is 
     essential for shared use of Coda across multiple organizations.

 (d) support for secure anonymous access to realms by clients without
     shared secrets available, allowing secure network booting over Coda
     and closing anonymous access security holes.


Once these changes are in place, Coda will indeed provide the level
of security built into its high-level design.    For now, be aware
that the actual level of security provide by Coda is still modest.
Security and scalability are the two focus areas for Coda in the 
coming months, so stay tuned......

Until the above implementation effort is complete, here are some
security-related deployment guidelines for Coda put together by Robert
Watson.  This is not a complete catalog of all possibilities, of
course, but just a sampling of the concerns to keep in mind.  Thanks
to Robert for taking the time to put these guidelines together.

                     -- Satya



Current Security Guidelines for Coda  (by Robert Watson)
========================================================

Authentication
--------------

1) Users should know that their Coda password is effectively being sent in
the clear, and that through DNS spoofing and other means, it is possible
to force the Coda client to send this information to other hosts than the
auth server.  As a result, they should not use this password for anything
but Coda.

With the strong crypto patches, this is no longer an issue;  similarly, we
believe that our Kerberos patches may be used to acquire Coda tokens
safely without risking the Kerberos login password or access to other
services via Kerberos. 

2) It is not possible to use the acquisition of Coda tokens for anything
but authentication to Coda--i.e., while it is safe to build a PAM module
that uses a password (not the login password) to retrieve Coda tokens, it
is *not* safe to rely on successful token acquisition to authenticate
users, or authorize them for login.  I.e., it is not a substitute for a
local password file, kerberos, etc.

To understand this limitation, consider the kerberos, which may be used to
effectively authenticate a user to arbitrary services (such as local
login): Kerberos provides each host ("service") an rcmd. or host/key--the
user's secret is used to acquire a ticket for the user, as well as an
authenticator to that service instance.  Only by using that authenticator,
is the user actually authenticated to the host.  Asssuming the use of the
strong crypto Coda token support, a Coda token can only be used to
authenticate a user if the authenticating service holds the Coda server
key.  Without the strong crypto patches, Coda tokens have limited use
beyond possibly discouraging fraudulent access to servers. 

Integrity
---------

Without the use of cryptographic hashes, Coda is unable to provide
integrity protection on packets in flight.  Users should not assume that
packets cannot be modified on-the-wire to subvert their requests.

Privacy
-------

Without the use of strong encryption, Coda is unable to provide privacy
protection for data carried and hosted by the filesystem.

Temporary Workarounds
---------------------

There are countless ways to subvert the Coda token acuisition process so
as to cause it to effectively give the user's password to arbitrary hosts. 
Through extensive uses of IP filtering, it is possible to limit the risk
associated with using Coda on an entirely trusted network, in which case
it might be safe to do this, but the IP filtering required is quite
extensive and requires a lot of thought to get right.

For the time being, it is probably important that users of Coda understand
that its support for on-the-wire security is quite limited, and as such to
avoid running under the assumption that it is secure.  As with NFS, direct
access to the wire over which Coda is used currently provides effectively
administrative access to the Coda realm.  While patches exist to largely
correct this, it may be a while before they are incorporated. 

A safe configuration of Coda (as found today) would probably include:

1) Eliminating remote access to the Coda server from untrusted hosts
(i.e., usable only within a trusted enclave) -- the easiest  way to
do this is to limit access at your border router.

2) Eliminate remote access to the Coda server from all untrusted users on
trusted hosts -- this is hard to do, and largely consists of restricting
access to your hosts to only trusted users.

3) Eliminate remote mariner access to clients from untrusted hosts/users.

4) Eliminate remote access to the callback port from untrusted
hosts/users.

There may be other issues here, and I'd welcome additions.

  Robert N M Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services