Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!rutgers!apple!bloom-beacon!athena.mit.edu!jfc
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: comp.unix.wizards
Subject: Re: NFS Security
Message-ID: <7059@bloom-beacon.MIT.EDU>
Date: 14 Sep 88 01:25:21 GMT
References: <1487@ficc.uu.net>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jfc@athena.mit.edu (John F Carr)
Organization: Massachusetts Institute of Technology
Lines: 73

In article <1487@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:

>Just how heavy a load (in CPU power, throughput, and un-unix-like behaviour)
>does the system used by Project Athena impose?

First, a description of the system he refers to:

  The Kerberos authentication system is designed for use in an insecure
  environment.  The fundamental assumption is that no machine needs to
  trust any machine other than a single server.  In addition, there is
  a site requirement that any Athena user be able to login on any of the
  several hundred workstations (except those reserved for individual use).
  
  .rhosts and duplicate /etc/passwd on all machines are acceptable for a 
  limited number of secure machines, but fail on large networks (consider
  the size of the passwd file for 6000+ users...then think of chaning it
  on each of 500 machines every time a user changes his password or a new
  user is added).  

  One problem is solved by having a common, central database to store such
  information as: 

     /etc/passwd entries for all users
     group lists
     location of NFS home directory
     location of mail server

  The other problem, authentication, is solved with Kerberos.  There are 
  a number of services for which authentication is desired, including:

     NFS uid mapping
     receiving mail
     sending certain types of messages
     access to the local equivalent of news

  Each service shares a private key with the kerberos server.  A user gets
  a "ticket" to use that service from Kerberos; this is encrypted using
  the service key and the user's key (the user first decrpyts the ticket
  with his key, then sends it to the server); if the server can decrypt it 
  then it can ID the user (since only Kerberos can encrypt with the service
  key).

  The exact sequence of encryption and details of message format are more
  complicated than I describe here.  It is possible for root on a machine
  to steal tickets out of the file (mode rw-------) in which they are stored, 
  but it is in principle possible for root to read a user's files in UNIX 
  regardless of any security.

The performance impact:

  Programs which require authentication have been re-written to use
  kerberos without any change in the user interface (an initial ticket
  is obtained at login and used to get more as needed).  As long as
  the ticket has not expired, the change is invisible.  Where possible,
  unauthenticated versions are kept as fallbacks (so, a failed kerberos
  rlogin tries again with the standard rlogin).

  CPU time is a consideration, since encryption is required.  In the present
  implementation, most net traffic after the initial authentication is not
  encrypted, so there is almost no performance impact.  I don't know how
  important it is for other applications (such as encrypted rlogin).  That
  it works on such a large network is evidence that it does not require too
  much time (else the server would overload).

  For NFS use, there is an option to require authentication for all mounts
  (and restrict access to a specific list), or to map unauthenticated 
  users to nobody.

  --John Carr
   John Carr             "When they turn the pages of history,
   jfc@Athena.mit.edu     When these days have passed long ago,
                          Will they read of us with sadness
                          For the seeds that we let grow?"  --Neil Peart