> FYI, NFS protections against black hats are weak to nonexistant.  All
> you need to access an NFS server is an IP address, an IP port, and an
> NFS directory handle.  All three may be sniffed off the wire between a

NFS is cheese.

> 
> It would be nice if Coda was secure.
> 

Survey: AFS, DFS, NFS:

AFS RPCs are authenticated but not encrypted. DFS DCE RPCs
can be authenticated as well as encrypted over the wire. Secure NFS exists,
but is not available on every vendor platform. Secure NFS uses RPC with the
AUTH_DES flavour of packet-authentication. AUTH_DES uses Diffie-Hellman
Key Exchange betwixt client and server with DES ciphering of the entire
RPC packet.  NFS using RPC with AUTH_UNIX authentication is mega-cheese.

explanation follows:

The client kernel is "trusted" by the NFS server to hoenstly stuff your 
Unix UID and GID into the RPC header. The server gets the RPC and compares 
your alleged Unix UID/GID with the mode-bits and UID/GID of the file that
you want to access. It is rather trivial to build an NFS client using
the NFS RPC interface definition that allows you to arbitarily impersonate
any Unix user that you desire - hence, MEGA CHEESY.

AFS, DFS:  Using your Kerberos TGT, you acquire an authenticator for
the "service-principal" that your fileserver daemons run as. For AFS,
you get an authenticator for afs._at_MYCELL.EDU. The authenticator can then
be send to AFS fileserver FOO.MYCELL.EDU in an RPC for a file fetch or
store. The AFS fileserver can now verify whom you are by decoding the
authenticator with a private key stored on the fileserver machine. DFS
uses the exact same game, except every fileserver has its own
principal, therefore, the kernel has to store an authenticator for you
for every fileserver machine that you contact. i.e:
	
	/.../mycell.edu/hosts/fooserver1/dfs-server
	/.../mycell.edu/hosts/physics/dfs-server


Whatever Coda's RPC uses simply needs to establish a shared secret
key between the Coda client and the fileserver. MD5 the RPC payload,
encrypt the MD5 with the shared secret key (perhaps some time-stamps
or nonces to thwart skilled code-breakers).  Stuff it to the wire: you have
packet privacy. 

Another alternative is to tunnel the serialized RPCs through a secure channel 
(i.e. GSSAPI) that proxies the interface to the network stack.

Ultimately, you have to have the crypto stuff in the kernel to seal/unseal
the RPCs. You have to have a way to let user-land processes stuff their
authentication credentials into the kernel so the secure RPC layer
can use the keys to cipher the traffic streams on behalf of the users
request.

Hence - my inquiry about a "clean" way of encapsulating and propagating
credentials in the Unix "struct proc" model. There HAS to be a way of
doing this that is clean, makes sense, and can make everyone happy.

-- Jim

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jim Doyle                         Boston University   Information Technology
Systems Analyst/Programmer        email: jrd_at_bu.edu   Distributed Systems
						      tel. (617)-353-8248
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++--+-+-+-+-+-+-