Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!GVAX.CS.CORNELL.EDU!jqj From: jqj@GVAX.CS.CORNELL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: More NFS discussion Message-ID: <8612281219.AA16219@gvax.cs.cornell.edu> Date: Sun, 28-Dec-86 07:19:40 EST Article-I.D.: gvax.8612281219.AA16219 Posted: Sun Dec 28 07:19:40 1986 Date-Received: Sun, 28-Dec-86 11:35:16 EST References: <4889@cornell.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jqj@gvax.cs.cornell.edu Organization: Cornell Univ. CS Dept. Ithaca NY Lines: 34 Approved: tcp-ip@sri-nic.arpa In article <4889@cornell.UUCP> nowicki@Sun.COM (Bill Nowicki) writes: >Let me try to correct some misconceptions: > ..., NFS has no security or authentication. >Authentication is done at the RPC level in a very open-ended >manner. The default in the first implementation was to trust UIDs, >since that is all that Unix provides. A scheme based on public-key >encription has been discussed in papers (Goldberg and Taylor, Usenix >conference 1985). Although Bill is technically correct, it still seems fair to say that "NFS has no security or authentication" and that this is a VERY serious weakness of the SUN NFS standard. SUN RPC is open ended in this regard, but the only form of authentication standardized is "UNIX-style" i.e. none. Since SMI has not officially endorsed the Goldberg&Taylor scheme, the situation is far worse than a simple lack of implementation. The fact remains that one can easily break security on any SUN NFS cluster if he/she has access to any diskless client. More abstractly, it is arguable that authentication at the RPC level is inappropriate for application-level security. It requires that the application (NFS) have a much closer coupling than I would like to the transport mechanism (RPC). As an example of the problems that this confusion of layering causes, consider how you'd handle a file system type that required secondary authentication, e.g. a Tops-20 like system that had both user id's and file "accounts", with perhaps a password associated with the account -- seems to me your NFS-level authentication scheme must of necessity be specific to the particular type of remote file system if you want file security equal to what you have in a local file system. For comparison, consider Authentication in the Xerox Filing (distributed file system) protocol, which is much more robust than anything I've seen considered as an NFS extension (but which still has major flaws...). See "Authentication Protocol", XSIS 098404, and "Filing Protocol", XNSS 108605.