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.