(Illustration by Gaich Muramatsu)
> 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 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++--+-+-+-+-+-+-Received on 1997-12-10 18:38:42