Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!uunet!timbuk!poplar13!bstrand From: bstrand@poplar13.cray.com (Brad Strand) Newsgroups: comp.protocols.nfs Subject: Re: NFS Security Message-ID: <124913.10184@timbuk.cray.com> Date: 8 Mar 91 19:31:44 GMT References: <1991Mar7.230410.2209@tandem.com> <13201@darkstar.ucsc.edu> Distribution: comp.protocols.nfs Organization: Cray Research, Inc., Eagan, MN Lines: 31 In article <13201@darkstar.ucsc.edu> haynes@felix.ucsc.edu (99700000) writes: > >I couldn't reply to the address in the original posting. > >MIT uses Kerberos authentication for NFS operations. Technically, this is not true. The MIT implementation of Kerberized NFS provides Kerberized authentication only for client communication with the server mountd, which modifies table entries in the remote kernel. There is nothing Kerberized in the NFS requests themselves. This, IMHO, drastically reduces the security of the implementation. Since there is nothing in the NFS request which allows the server to determine its authenticity, it's really not much more secure than regular old NFS (*). Anybody on the same host (IP_addr) as me can build a fake NFS request, and the server would be none the wiser. Be sure you understand that the Athena solution to authenticated NFS does not apply well to multi-user clients. * Yes, I understand that this is not a problem in MIT's world of single-user workstations and fileservers. And, yes, I understand that attacks to Kerberized NFS are limited to periods when clients are actually registered with remote servers. -- Brad Strand bstrand@cray.com (DOMAIN) uunet!cray!bstrand (UUCP) Cray Research, Inc. Networking and Communications Development 655F Lone Oak Drive #include Eagan, MN 55121 "No gnu taxes."