Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!brad@seismo.CSS.GOV@sun.UUCP From: brad@seismo.CSS.GOV@sun.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8612310738.AA04465@sun.Sun.COM> Date: Wed, 31-Dec-86 02:38:36 EST Article-I.D.: sun.8612310738.AA04465 Posted: Wed Dec 31 02:38:36 1986 Date-Received: Wed, 31-Dec-86 05:39:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 90 Approved: tcp-ip@sri-nic.arpa Path: sun!brad From: brad@sun.uucp (Brad Taylor) Newsgroups: mod.protocols.tcp-ip Subject: Re: More NFS discussion Summary: Clearing the air about authentication and NFS Message-ID: <10911@sun.uucp> Date: 31 Dec 86 07:38:36 GMT References: <4889@cornell.UUCP> <8612281219.AA16219@gvax.cs.cornell.edu> Organization: Sun Microsystems, Inc. Lines: 79 There are many misconceptions about authentication. Let my try to clear them up. > 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. The statement "NFS has no security or authentication" is simply not true. There *is* a limited form of security with UNIX authentication. If you trust all of the nodes connected to the network, then the entire system is secure. We know this assumption is unreasonable in many cases, and that is why we proposed the alternative system. In the alternative system, you do not have to trust your network. It also fixes the other problem with UNIX authentication, that being that it is to UNIX-oriented (good name for the authentication system, eh?). In the alternative scheme, users are not reference by a uid, but by a string of characters only and a database is used by the server to convert from the string into the particular form of authentication required by the OS. For UNIX, it's uids, but other operating systems are free to map it into something else. > 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. Wrong. The situation is no more than a lack of implementation. And again one must have more than mere access to a client machine to break security with the UNIX form of authentication: you must have root access to do it. (With the proviso being that, on Unix at least, init is changed to prompt for a password during single user boots: a simple hack). > 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). First of all, RPC is not a transport protocol. Secondly, it makes a lot of sense to put authentication at the RPC level. Think of the analogy to transport protocols, where you can think of the source address as a primitive form of authentication (and used as such by many network applications). Also, implementation-wise, since all of the RPC applications have the RPC code in common, it is a natural place to put the other thing they have in common here too. I don't feel this is a very important issue though. What's far more important than layering is how secure and general purpose the authentication system is. > 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. Nothing in the RPC protocol prevents you from implementing your TOPS-20 authentication scheme, since RPC can support several authentication schemes. We aim for more general purpose authentication systems than this, though. > 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. Well, if you like the XEROX protocol so much, then you'll should like our proposal too because it's pretty similar. (By the way, the date on the paper describing the alternative system is 1986, not 1985 as stated above).