home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / protocol / kerberos / 681 < prev    next >
Encoding:
Text File  |  1992-09-09  |  4.9 KB  |  99 lines
  1. Newsgroups: comp.protocols.kerberos
  2. Path: sparky!uunet!stanford.edu!OCFMAIL.OCF.LLNL.GOV!nessett
  3. From: nessett@OCFMAIL.OCF.LLNL.GOV (Danny Nessett)
  4. Subject: Re:  Existing authentication mechanisms have a deficiency
  5. Message-ID: <9209091614.AA15084@ocfmail.ocf.llnl.gov>
  6. Sender: news@shelby.stanford.edu (USENET News System)
  7. Organization: Internet-USENET Gateway at Stanford University
  8. Date: Wed, 9 Sep 1992 16:14:34 GMT
  9. Lines: 88
  10.  
  11. Glen Zorn writes,
  12.  
  13. > I think you may be confusing authentication and authorization:even if a system
  14. > were completely Kerberized for authentication purposes, you would still need
  15. > some way to specify which principals were *authorized* to perform various
  16. > tasks, access local files, etc.Probably you would want this control to reside 
  17. > locally, or at least be configurable on a machine-by-machine basis -- I might 
  18. > be trusted to administer a software development system, but not to browse
  19. > the company's payroll files. That's where the /etc/passwd file (or its
  20. > surrogate) comes in, in specifying which users (however they are
  21. > authenticated) are allowed what type of access (if any) to the local system.
  22. > 
  23. > ~ Glen
  24.  
  25. Similarly, Ted Ts'o writes,
  26.  
  27. > 
  28. > Yup.... what's missing is "an authorization mechanism".  Both Kerberos
  29. > and SPX purport to offer an "authentication", and completely punt on the
  30. > "authorization" issue, leaving that as an exercise for the application
  31. > writer to deal with.
  32. > 
  33. > While this may seem to be an amazing cop out, since every nearly every
  34. > application which uses the authentication services provided by Kerberos
  35. > or SPX will require some sort of authorization policy, even if it is as
  36. > simple as checking an ACL, file, there is a good reason for this design
  37. > choice.  And the reason is this:  
  38. > 
  39. >     While authentication systems are relatively well-understood at
  40. >     this point, authorization policies are not.  
  41. > 
  42. > Specifically, there is no good, general model which shows what sort of
  43. > functionality an system would need in order to provide a completely
  44. > general authorization policy which would work for all possible
  45. > applications.  There have been attempts to do so --- ECMA has issued one
  46. > or two technical reports which try to do so --- but they tend to be
  47. > fairly confusing, and it is not clear at least to me whether they
  48. > generate more light than heat.  So it seems fairly clear to me that a
  49. > workable authorization framework is at least partially still an area for
  50. > research.  
  51. > 
  52. > What we use at MIT Project Athena is a system called "Moira" to handle
  53. > our authorization policies.  Specifically, it is a database system which
  54. > automtically distributes configuration files to most of the Project
  55. > Athena servers every night.  This allows most of the authorizatrion
  56. > information to bee kept in exactly one place, as your requirement
  57. > specifies.  Since connections to Moira require a Kerberos-authenticated
  58. > connection, reasonable access list control can be placed on the Moira
  59. > database, and it is even possible to figure out who made what
  60. > modifications to a particular database entry.
  61. > 
  62. > Moira is big and hard to set up (it runs on top of Ingres), so it may
  63. > not be appropriate for all sites.  But it is one solution which keeps a
  64. > large part of the authorization information in one centralized place.
  65. > 
  66. >                             - Ted
  67.  
  68. While I agree that authorization is a topic that has not been adequately
  69. treated yet in regards to distributed systems, I think you missed my point.
  70. The /etc/passwd file carries alot of information about a user including
  71. his encrypted password, his uid, his personal information, etc. It is also
  72. true that /etc/passwd couldn't simply be eliminated unless the data about
  73. a person that is kept there is stored elsewhere. However, my point was
  74. about authentication; I was not addressing the general question of eliminating
  75. /etc/passwd. 
  76.  
  77. One could imagine a system configured so that all on-machine authentication
  78. requests contacted the appropriate server, say the Kerberos server or
  79. SPX LEAF server, rather than looking in /etc/passwd for the user's
  80. encrypted password. Actually, I think SUN already does something like this
  81. by looking in the NIS (aka Yellow Pages) database for a user's encrypted
  82. password. Moving the authentication information off-machine has the advantage
  83. of centralizing the data, allowing it to be protected more carefully at lower
  84. cost, providing a single point of administration for authentication, etc.
  85. My suggestion about modifying su to contact the appropriate server to
  86. perform authentication was along these lines.
  87.  
  88. By the way, I'm not claiming that such a scheme is problem-free. It means
  89. locating and changing all programs that access the encrypted password
  90. field of /etc/passwd and changing them to call a routine that authenticates
  91. using the central server. This requires not only new code, but also maintenance
  92. of these modified programs as the central authentication systems change from
  93. version to version.
  94.  
  95. Regards,
  96.  
  97. Dan
  98.  
  99.